Urban Turtle's blog

Assisting teams and organizations adopt Scrum and Agile practices for many years, I have realized, sometimes the hard way that Agile is a culture change. If you are interested in exploring more the topic of cultures and their implications, there are many resources available. I suggest you have a look at Bill Schneider’s work. I also suggest this blog post from Michael Spayd.

I have found Schneider’s core culture model very useful to assess the culture in place in a group that wants to adopt Scrum and Agile. Depending on how much time you want to allow, you can do an intuitive assessment or have some people go through the questionnaire that you can find in the book The Reengineering Alternative. By having the questionnaire by multiple persons at various levels and with various roles in the organizations, you can develop a good understanding of the culture in place. With the assessment results in hand, you have a marvelous tool to drive conversations and start identifying the challenges of the transition to Scrum and Agile and where to focus efforts.

Adopting Agile will certainly bring significant challenges in creating a team/collaboration culture, solid incremental software engineering practices, value driven planning, etc. Therefore, the last thing you want is tooling to get in the way. I have found that people put too much focus on the tooling for managing their scrums and not enough focus on the core issues. My advice, especially in the early stages of a product or project, is to use the tools that will provide the highest level of collaboration and interactions. Those are collaborative sessions where you use flip-charts, post-its, whiteboards, etc. Until we have tools that support a very high level of interactions and allow teams to create story maps and other models collaboratively and efficiently, I think it is wise to stick with those simple tools in those product exploration and definition sessions.

For various reasons, a significant portions of the Scrum / Agile teams will want to use an electronic tool to do planning and tracking. Again, I think the best tools are the ones that do not get in the way of collaboration. As outlined in Scrum and Agile Built Into Microsoft Team Foundation Server I presented how we design Urban Turtle to blend much like a chameleon into the existing environment for organizations that are using Team Foundation Server. The Urban Turtle team is committed to enabling software teams to create kick-ass software fast and we are always striving to make the user experience seamless and simple. Give Urban Turtle a try and please let us know what you think we need to improve in Urban Turtle or what you think we completely got wrong. Please be candid. We have done a release per month (5) since the release of TFS 2010 and intend to continue sustaining this pace. Therefore, there is a high chance that if your suggestion is great, it will be included in the product soon.

I value a lot exchanging points of view and experiences. Please do not hesitate to comment here, or send me an email to setup a live conversation.

In a previous post, Sprints and Compelling Goals, I expressed my opinion on why I think commitment driven planning is much more powerful than capacity planning. In the next post I will present why I think compelling goals drive collaboration and creativity. Stay tuned!

Cheers,
~françois

Note that the ‘Scrum Team’ refers to the Product Owner, the ScrumMaster and the Team. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.

Last week I was discussing with Mathieu and he started to talk to me about a friend who is now Product Owner (previously project manager) on a Scrum project. This person wants to make sure he is doing a good job and wants to continuously improve. I said, this is really awesome!

Mathieu, then says that his friend asked him the specific question: if I want to track the time I am investing in creating user stories and prioritizing the product backlog, which work item type and fields should I use to enter actual time spent if I am using the new Scrum process template from Microsoft.

My reaction is … Interesting, why don’t you ask your friend how he is going to use this data to effectively improve as a Product Owner? If the Team is producing software that the users consider high value at an ever increasing and sustainable pace, don’t you think that those are great indications that the Scrum Team is doing good work? I believe those are much more interesting metrics to track than the actual effort he is putting in creating and prioritizing the product backlog.

Mathieu: Sure, I will suggest him that but I think he also wants to track cost.

Ha! This is getting even more interesting now. Because it leads to the questions of time and cost tracking in Scrum; a question I often get in my scrum classes, especially from participants working in large corporations.

When I started teaching Scrum in 2004, I used to answer in my classes that time tracking is not part of Scrum but if you want to track actuals on sprint backlog items for administrative purposes, you can go ahead.

Observing Scrum Teams doing time tracking on sprint backlog items invariably leads them to questions like:

• Where do we put the time for meetings?
• Do we need to have absolutely all tasks in the sprint backlog?
• When we are pairing, do we do time entries for each of us?
• When we plan, do we create tasks for all the available hours we have? (more on this in the post Sprint and Compelling Goals)

And the list goes on. All these questions are a struggle for the Scrum Team and answering them does not help them in creating high value software fast. Therefore, my answer now is: Tracking actual work on sprint backlog item is not part of Scrum. Period.

The reaction I usually get is either “this is impossible in real life” or “you are telling us that a Scrum Team is not responsible for its cost”.

I think that a Scrum Team IS responsible to be aware of their cost and the value they bring to the organization; they are software professionals and therefore they strive to maximize the ROI of their work. The Product Owner is specifically accountable for maximizing the ROI by appropriately prioritizing the product backlog.

The reaction is usually “I don’t get it. You are saying not to track actuals on sprint backlog items and at the same time that the Scrum Team is responsible for its cost.”. Here is the suggestion I usually provide. Most organizations are interested in knowing how many hours their people work to be able to produce the pay checks. Therefore they have a timesheet system where people enter their time. My suggestion is to have time entries per project (much higher level of granularities than the sprint backlog items). Therefore, a team member working on a single project will produce one time entry per period. Timesheet system or not, you should be able to easily query your enterprise systems to know salary costs for a given period. May be you are lucky enough to have a cost tracking system in place that is able to give you the answer to how much expenses directly related to the product development were made during the same period.

My point is that it should be possible to identify the total cost of an iteration and have the Scrum Team track this. Considering all of this, I have a request to make to Microsoft : Add the fields ‘Scrum Team Cost’ (numeric) and ‘Other Costs’ for iterations in the Scrum process template. This will be useful for enterprise Scrum. May be it is not too late to put it before version 1.0 goes final

Cheers,
~françois

There has been a debate in the Scrum and Kanban communities about having iterations  (sprints) or not. I am worried that this blog post will generate flame wars and rants. Thus, there will certainly be some energy that will be lost. My hope is that this post will generate real debates and discussions so we can learn from each other’s opinion.

I have been developing software in Scrum for a long time and coaching many teams and organizations adopting Scrum. Therefore, I have been exposed to a lot of situations and feel I have integrated the fundamentals and the theoretical foundations of Scrum.

My general feeling, which you will see expressed throughout this blog post is that the Agile community is falling into the trap of looking for optimizations everywhere and is losing sight of some fundamentals about complexity, creativity, teamwork and commitments.

When I first heard about Kanban, I was intrigued and read about it and even applied it in some situations I felt it could be helpful. There are a couple of nice things that Kanban brings to the table but I also think that it breaks some fundamental things that make Scrum work.

Within sprints, Scrum suggests a simple workflow with sprint backlog items going from ‘To Do’ to ‘In Progress’ to ‘Done’. I have certainly seen some Scrum teams have way too much work ‘In Progress’ and using Kanban techniques to limit the amount of work in progress can certainly help. I also do not think it is necessarily a bad idea that a mature team establishes a more defined workflow and uses Kanban techniques to control its flow of work but going too far (I have seen a Kanban board with 10 columns corresponding to stories’ statuses) in that direction will reduce the possibilities of emergence that creates true performance in self-managing, multidisciplinary teams.

Getting to the actual debate of having sprints or not. Some Scrum proponents say that not having sprints may be problematic because the team needs to hold regular retrospectives to accelerate learning. While I do agree that holding regular retrospectives is absolutely essential, I think that a Kanban team could do regular retrospectives while not completely applying sprints.

I think Ken Schwaber has a much stronger point. In his Waterfall, Lean/Kanban, and Scrum blog post, he presents sprints from the point of view of the complexity theory.

A container is a closed space where things can get done, regardless of the overall complexity of the problem. In the case of Scrum, a container is a Sprint, an iteration. We put people with all the skills needed to solve the problem in the container. We put the highest value problems to be solved into the container. Then we protect the container from any outside disturbances while the people attempt to bring the problem to a solution. We control the container by time-boxing the length of time that we allow the problem to be worked on. We let the people select problems of a size that can be brought to fruition during the time-box. At the end of the time-box, we open the container and inspect the results. We then reset the container (adaptation) for the next time-box. By frequently re-planning and shifting our work, we are able to optimize value.

Vincent also brings an interesting viewpoint in his recent post Scrum is not about project management
.

While explaining the notion of container, Ken mentions above: “We put the highest value problems to be solved into the container.” I would like to push this a little further and relate it to planning and commitment. I have always insisted in my Scrum classes that a successful sprint planning is not about delivering a sprint backlog, it is first and foremost about having a team committed toward a goal that is compelling for them as a whole including the ScrumMaster and Product Owner. I believe, this is one of the fundamentals to create creative hyper-performing, self-managing teams that can sustain.

I have felt during the last few years that as a community we are putting too much focus on the concept of velocity and, therefore, many teams are un-passionately identifying their commitment based on their velocity and do not get to the true nature of what it means to be committed toward a compelling goal.

Before you throw tomatoes at me, I am not saying that measuring velocity is useless. I am saying that while it is useful for a team to measure and be aware of its velocity, I think we let it drive too much the commitment decisions of the team. Some tools are in my opinion putting too much emphasis on using velocity to drive the sprint planning process.

This belief of the importance of being committed toward a compelling goal was reinforced recently while reading the following book: The three laws of performance. Here are the three laws presented in the book:

1. How people perform correlates to how situations occur to them.
2. How a situation occurs arises in language.
3. Future-based language transforms how situation occurs to people.

I will not try to summarize the book here. I thought it is useful to mention this reference because I think it links the importance of creating an environment in planning sessions that enables the team to choose a goal that is compelling for them to some fundamentals of human beings.

In summary, I suggest to use sprints as defined in Scrum because when done in the true spirit of Scrum, they enable a team to look at the highest value problems, imagine a compelling future, and use all of the thinking, collaboration, and creativity possible to put together solutions and plans. Then, you leave the people alone within the container of the sprint to apply their professional skills, without interruption so they can concentrate and focus on their work. This is the core of them being creative people doing creative work rather than resources being managed to optimize productivity.

In Answering some common questions about Urban Turtle we answer some questions and present some of the orientations we took in designing Urban Turtle.

One of the main orientation is to build Urban Turtle into TFS (as opposed to integrate with). All our design decisions are made to bring as much value-added as possible while creating a seamless experience for existing TFS users and grow with TFS as Microsoft adds new features.

We believe this orientation is what allows us to have a product that installs on the server in less than two-minutes and gets a team to use it right away. We are very interested in hearing your stories and get your feedback about how we can further improve the experience.

Help us make our Urban Turtle a Chameleon

Also, our tight integration in the Web Access user interface makes the user feel at home and perceive TFS with new capabilities (as opposed to using an extra product). This is a big plus to have a smooth user adoption. We know that adopting scrum is already an interesting challenge; you do not need tools to get in your way but be a possible accelerator.

In the release that we have for you this week (June 2nd), we deliver a bunch of enhancements including a productive way to use Areas. The upcoming release will most likely focus on a feature we call Perspective that will allow you to work seamlessly in Urban Turtle on a subset of work items making it a charm to do multi-teams and grouping projects together. We will also focus on enhancing user experience in a couple of key places.

Again, give Urban Turtle a try and let us know how we succeeded in turning it into a Chameleon.

Most successful Agile/Scrum teams use a multi-level planning approach. There are a couple of quotes that I like and always mention in my Scrum training:

“Planning is everything. Plans are nothing.” – Winston Churchill

“No plan survives contact with the enemy.” – Helmuth von Moltke the Elder

I think they are good guiding principles.

Lets have a look at how Urban Turtle supports teams that use multi-level planning. Here we will use an example with releases and sprints but note that you can use as many levels as you want. However, if you decide to add more levels as a team, make sure they are truly needed and they are not just inducing extra complexity.

In this blog, I will use the user story and sprint terms because they are very common. Note that terms may vary depending on the process template you are using. Urban Turtle ships with mapping files for some popular Agile/Scrum process templates. It is very easy to create a simple XML mapping file to use Urban Turtle with almost any process template. For those who have their own customized process template, we will shortly write a blog entry that will explain how to easily create the mapping file.

During early project planning, the team will create some user stories and use Urban Turtle’s drag and drop capabilities to prioritize their product backlog.

When the team is ready for release planning, it is time to add the next release and some sprints. Here I have a sample release with three sprints.

Note that it may be tempting to try and schedule up-front every story in specific sprints, but our experience shows us that it is better to defer the decisions and let the team inspect and adapt as it achieves some sprints. By deferring the commitment as much as possible, the team takes ownership of their backlog and their planning activities. In other words, have the team evaluate their capacity for the release based on past velocity and commit user stories in the release according to this.

Note that because Urban Turtle computes all the statistic roll-ups, if the team is sure that a story needs to be done in a particular sprint, they can simply commit it to a sprint via drag and drop. In doing so, the release view will not be affected. When the team will get to the sprint planning for this particular sprint they will see an that the user story is already committed.

During the first part of a sprint planning activity, the team identifies its commitment for the next sprint. The team goes to the current release and checks the option to display only user stories that are not yet committed in a sprint. Then they drag and drop the stories they want to plan in the sprint until they feel they have reached their capacity.

Note again that Urban Turtle does all of the roll-ups for the user, allowing to have the statistics for your releases and sprints at a glance.

During the second part of sprint planning, the team creates the tasks that constitute their sprint backlog.

I hope that this blog gave you a good idea how Urban Turtle supports teams in their various planning activities while keeping the flexibility of not dogmatically following the suggested process.

Happy planning.

~francois

Last week we were in Las Vegas at devconnections for the launch of Visual Studio 2010 and to present the new version of Urban Turtle. We often got the following questions :

1. Do we need to install anything on the workstations?
2. What happens if I customize the process template to fit the specific needs of my organization?
3. Does UrbanTurtle interfere with other tools from Microsoft, other vendors or that we could have developed?
4. What are your plans?
5. What is your pricing?

Do we need to install anything on the workstations?

From the beginning, our goal is that Urban Turtle users do not feel as if hey are using another product. We want to increase their comfort and simply extend their usage of Team Foundation Server (TFS). To achieve this, we did several things. The main one is that the user interface seamlessly blends in with Web Access of TFS. Therefore, there is just a one-time installation process on the server.

Furthermore when we developed the new installation process for the VS 2010 compatible version, Dominic’s (the Product Owner) condition of satisfaction was that the installation takes less than 5 minutes. The team over delivered because most of the time, the installation takes less than 2 minutes. If your installation takes longer, please let us know.

What happens if I customize the process template to fit the specific needs of my organization?

We know by experience that a lot of organization will want to use a standard process template and customize it by adding some fields to some work items or slightly customize some workflows or … In other words, there is no one way of doing Agile and Scrum. Therefore we designed Urban Turtle to let you take advantage of TFS’s customization capabilities; Urban Turtle is designed to be process template independent. It only needs to know a couple of things about your process template. This information needs to be put in a simple XML file. We will shortly write a blog entry that will explain how to easily create the mapping file. In the meantime, do not hesitate to ask questions on the forum

Does UrbanTurtle interfere with other tools from Microsoft, other vendors or that we could have developed?

No, Urban Turtle does not interfere with any tool.

Again our goal in designing Urban Turtle is that it seamlessly inserts itself in the TFS ecosystem. To achieve this, we decided to rely on standard extension mechanism and not have a separate data store. Urban Turtle directly manipulates work items using the standard APIs.

This allows us for example to validate the workflow transitions in the task board even if you customize your workflows. Also, since you customize your work item fields using standard mechanism and Urban Turtle does not add extra data, the powerful reporting and data warehousing capabilities of TFS will not be affected and will work as documented by Microsoft.

What are your plans?

The team is currently in the last sprint to release version 3.0. The product, the development environment and the team are now in a mature enough state to do solid public releases every 4 to 6 weeks. We will publish a blog every sprint to announce what we are working on.

What is your pricing?

I hope this answers the most common questions. If I missed some, do not hesitate to ask.

Do not hesitate to turtle your TFS, you are less than 5 minutes away!

~francois