The Agile Adoption Mixing Board

When I talk to clients about adopting the basic values from the Agile Manifesto, I tell them to imagine sliders between the four entries on the left and right. A good adoption is like mixing a band and as the band plays you adjust the mix constantly to get the best sound. Purists may claim you must adopt each value to its fullest which is like sliding all the sliders on the mixing board to one side which never sounds very good.

I’ve had a client who had recently invested in offshore resources and a new remote office for the development teams. They could not immediately get the development team together so they could not fully embrace the “Individuals & Interactions” value or some of the practices attributed to it. So we used some tools like Skype, WebEx, and Team Foundation Server and put in a little process around communications between the sites to help retain some of the collaborative aspects of the team. So I see this like moving the slider on my Agile mixing board a little over to the right and the “Process & Tools” side. This client does see the value of having everyone together so there is a plan that once they can feasibly move development to one location, they will do so. And when they do we can remove some of the processes put in place and stop using the tools so the slider moves back to the left a little more.

Claims that you must adopt Agile in its entirety and never change your adoption to meet your current environment are not very practical for some companies. I definitely think you should always evaluate the impediments you perceive are preventing you from transitioning to Agile practices to ensure you are not reverting to muscle memory, but there are definitely real world scenarios that can make some adoptions possibly detrimental to the business if immediately (and blindly) adopted. I like this blog from Ryan Cooper about how conflict can arise from these situations.

So I think good Agile coaches are like good sound men who are constantly listening to the band and as the environment changes they adjust the mix appropriately. We listen to the team and the stakeholders to determine how much to adopt and what may have to wait for later. Anything that you do determine should wait needs to be logged with the following details:

• What it is exactly you are not going to adopt.
• What the benefit of adopting it would be.
• The cost of not adopting the practice.
• “Smells” that will indicate you should definitely adopt the practice.

This way we acknowledge that we are not adopting one of the best practices prescribed by Agile (or whatever flavor we are adopting) and then outline the cost and the return for justification later if the smells start to occur. This adoption log can also be great fodder for retrospectives.

So listen to your team and be vigilant when the environment changes so that you adjust your mix of Agile adoption to best fit the situation.

Comfortably Scrum: How Scrum Are You?

Many Agile pundits think that you are either Scrum or you are not. I disagree with the concept that being Agile or Scrum is a bit flag. Some companies cannot (or will not) adopt all of the Scrum/XP practices initially. You can call them ScrumBut, Scrummerfall, or whatever, but these companies can (and do) still get value from adopting some of the practices of Scrum/XP. They will not get as much benefit and their gains will depend on what combination of process and practices they do adopt. True some of these combinations can actually be counter productive, but I do not think it is fair to shun anyone who is trying their best to implement them.

So when someone tells me they have adopted Scrum, I usually ask a handful of questions to see what they have adopted and to what extent. These questions mainly come from the Nokia Test and specifically the version Jeff Sutherland introduced at my Certified Scrum Master training.

The Nokia Test is to be taken with a grain of salt since it mainly measures the mechanisms you have adopted and only slightly gauges then intent (or ideals) behind them. I do think it is a decent, initial litmus test to see how far your implementation has gone. I have added a few sections to the test aimed at the complimentary XP practices I think are needed for a well rounded Scrum shop.

Here is my version of the test based on Jeff's 2008 version. Determine how many points you get for each question, add them together and then divide by 10.

Question 1: Iterations

• No iterations - 0
• Iterations > 6 weeks - 1
• Variable length <>
• Fixed iteration length 6 weeks - 3
• Fixed iteration length 5 weeks - 4
• Fixed iteration 4 weeks or less - 10

Question 2: Testing

• No dedicated QA - 0
• Unit tested - 1
• Feature tested - 5
• Features tested as soon as completed - 7
• Software passes acceptance testing - 8
• Software is deployed - 10

Question 3: Specification

• No requirements - 0
• Big requirements documents - 1
• Poor user stories - 4
• Good requirements - 5
• Good user stories - 7
• Just enough specification - 8
• Good user stories tied to specifications as needed - 10

Question 4: Product Owner

• No Product Owner - 0
• Product Owner who doesn’t understand Scrum - 1
• Product Owner who disrupts team - 2
• Product Owner not involved with team - 2
• Product owner with clear product backlog estimated by team before Sprint Planning meeting - 5
• Product owner with release road map with dates based on team velocity - 8
• Product owner who motivates team -10

Question 5: Product Backlog

• No Product Backlog - 0
• Multiple Product Backlogs - 1
• Single Product Backlog - 3
• Product Backlog clearly specified and prioritized by ROI before Sprint Planning - 5
• Product Owner has release plan based on Product Backlog - 7
• Product Owner can measure ROI based on real revenue, cost per story point, or other metrics - 10

Question 6: Estimates

• Product Backlog not estimated - 0
• Estimates not produced by team - 1
• Estimates not produced by planning poker - 5
• Estimates produced by planning poker by team - 8
• Estimate error <>

Question 7: Burndown

• No burndown chart - 0
• Burndown chart not updated by team - 1
• Burndown chart in hours/days not accounting for work in progress - 2
• Burndown chart only burns down when task in done - 4
• Burndown only burns down when story is done - 5
• Add 3 points if team knows velocity
• Add 2 point if Product Owner release plan based on known velocity

Question 8: Team Management/Disruption

• External management disrupts team - 0
• Product Owner disrupts team - 1
• Product Owner or Scrum Master assigning tasks - 3
• Scrum Team assigns tasks - 5
• No outside disruptions, only Scrum roles - 10

Question 9: Build Automation

• No build automation - 0
• Continuous Integration build automated - 1
• Nightly build automated - 3
• Unit Tests run during nightly build - 5
• Feature tests run during nightly build - 7
• Deployment to other environments automated - 10

Question 10: Daily Scrum

• No Daily Scrum meeting - 0
• Daily Scrum meeting everyday - 1
• Daily Scrum meeting same time, place - 3
• Daily Scrum runs <>
• Add 2 if reported Impediments are logged
• Add 2 if tasks are directly updated during meeting
• Add 1 if only Scrum Team are allowed to speak

Keep in mind that Jeff told us his best client has a score around 8 and most shops score 6 or 7. I believe this shows that there is no perfect adoption and that all of us are working towards making our implementation better. My best client was around a 7 and it was a great shop to work in.

Let me know where your company lands and where you can improve!

Comfortably Scrum: IIBA Presentation "Introduction to Agile Development Using Scrum"

Tuesday, January 20th, I will be speaking at the International Institute of Business Analysis luncheon held at Belmont University. I will be presenting my Introduction to Scrum content with a more Business Analyst twist to it.

Comfortably Scrum: Man Cannot Live on Scrum Alone (Throw in a Little XP)

Many detractors of the Scrum framework claim it to be too thin and does not include the prescribed Agile engineering practices like XP. Scrum is actually supposed to be a very light weight framework for a company to adopt into the development process. It is minimalistic on purpose.

As far as the engineering practices, one does not have to search too hard to find all the primary originators of Scrum stating that it is a management wrapper for XP. The Control Chaos website has a good summary of the xp@scrum approach here. During my Scrum Master training, Jeff Sutherland himself featured the graphic below prominently in his first few slides and stressed how the engineering practices of XP were essential to getting more productivity out of any Scrum implementation. Ken Schwaber has also co-authored an article about combining Scrum and XP.



All of this information has been around for quite awhile and is fairly prominent, so I find it astounding that so many still see these approaches and not compatible. Jeff also told us in our training of the infamous email he received from Kent Beck in 1995 asking for more information about Scrum so he could incorporate it into his approach:

"Is there a good place to get reprints of the SCRUM paper from HBR? I've written
patterns for something very similar and I want to make sure I steal as many
ideas as possible."

In general, Scrum leans more towards a management process that supports Agile development processes like the ones prescribed in XP. I personally believe that you cannot be very successful with Scrum without implementing things such as Continuous Integration, Unit Testing (TDD), Coding Standards, Small Iterations, Sustainable Pace, etc.

I also think Scrum is a bit more acceptable to the masses (which some people also site as a detractor) that a pure implementation of just XP. It is called extreme programming for a reason!

Hopefully this combined approach will be what people implement rather than just adopting the Scrum mechanics and continuing to develop with their same, non-agile methods. This would most likely lead to failure and that usually gives people the impression that the reason for the failure was Scrum.

Comfortably Scrum: My Common Product Backlog Work Item Customizations

For the last half of this year I have spent the majority of my time helping various clients adopt Scrum and Agile engineering practices using Visual Studio Team System and Team Foundation Server. After initial Scrum training and an overview of TFS, we will customize the implementation to fit each company's individual needs. I am a big fan for Conchango's TFS process template for Scrum and their work item template for Product Backlog items is the template I extend the most. Here are some of the most common changes and additions I make to this item for my clients.

First I change few of the labels for the standard fields from the Conchango template:

Business Priority is changed to Business Value since the word "priority" has a certain connotation of order. I also implement a SuggestedValues rule with values ranging from 100 to 1000 with increments of 100 (100, 200, 300, etc.).

Estimated Effort (days/story points) is changed to just Story Points since I really encourage teams to not use days or hours when estimating the Product Backlog. I add a SuggestedValues rule to this field with the Agile standard of the Finbonacci sequence variation (1,2,3,5,8,12,20,40,100). Some clients use the planning poker cards from Crisp, but I do not include 0, 1/2, ?, or the Coffee Break card.

I also change the description on the Conditions of Acceptance section to include "or How To Demo Steps" since I really like using this technique over just a bulleted list of acceptance criteria.

I also add two new fields:

Return On Investment which is a read only field calculated by dividing the Business Value by the Story Points. We use this as additional perspective when ordering the Product Backlog. The value is updated by a web service created using Howard van Rooijen's project template for TFS event subscription end points.

Product Backlog Type which is used many different ways depending on your Agile tool or general philosophy. My version has three allowed values:

• User Story which is exactly what it sounds like. All these entries must fit the user story format.
  


• Technical Requirement which is for any behind the scenes work like refactoring, building supporting components with no UI, etc. This helps identify which items require functional tests to be created (meaning a User Story) or those that just need to be regression tested with the current suite of tests.
  



• Epic which is used for placeholder entries. Some people like to use TFS Areas for this but I prefer to put it at the Product Backlog level. It allows stakeholders to throw pie in the sky ideas on the backlog. Our rules specify that an Epic is not estimated, is always last in delivery order, and can never be added to a Sprint until it is broken up into acceptable User Stories with a Story Point value that can be done in half a Sprint.

I also add some new work flow steps:

Ready For Test is something the Conchango template puts at the Sprint Backlog level and I prefer to have this measured at the Product Backlog level. There is some contention on this even on the Conchango forums. My thought is that a task like "Create class to hold search criteria." cannot be tested but its corresponding User Story ("Search Online Catalog") can be.

Failed Test and Passed Test are two optional steps I sometimes put in to follow Ready For Test. This depends on how integrated the testers are with the development team. If they are very integrated and the team is good with simply communicating failed and passed tests verbally or via email then these can be left off. I have had less integrated QA teams that were also not co-located with the team and we found these steps necessary to keep up with test results.

And finally I organize the form a bit to keep it symmetrical and grouped a bit more clearly.

These changes are not necessarily a good fit for every team and I really try to understand the level at which each client can adopt the Scrum processes before we run head first into customization. I have found these changes to bring value to the process for the majority of time.

Comfortably Scrum: Sprint Planning Using Conchango’s Sprint Task Board Application

After my last blog post about the Agile features in the upcoming 2010 release of VSTS and TFS I got to thinking about some comments by Jeff Hunsaker. I had complained about the lack of good Sprint planning features in TFS and Jeff had mentioned using the Sprint Task Board WPF application provided by Conchango to work with their Scrum process template for TFS. I have used this in my Daily Scrums but had not really thought of it as a planning tool. I revisited that idea after Jeff’s comments and I will say it does have some features around this that I had not thought of using before.

When you open the Sprint Task Board you are prompted to choose a project then choose a Sprint. The Sprint you choose is actually an item in the hierarchical list of Iterations. I have always just selected my specific Sprint, but if you choose a Release you will then see all of the Product Backlog items under that release. So if you have previously performed your Release Planning and assigned Product Backlog items to their projected releases then they should show up. The image below is a view of a sample Product Backlog viewed in Excel. Notice that all but one item is assigned to the Release 1 Iteration.

When you open the Task Board application and choose Release 1 for this project you will see all of the items that were associated to Release 1 (or a Sprint in that Release). Anything not assigned to that Release will not be shown.

At this point you could start a Sprint Planning meeting using this interface a add Sprint Backlog Items to each Product Backlog by rights clicking anywhere on the row and choosing Add Sprint Backlog Item. You can fill out the pop up form and a new Sprint Backlog item will be created and linked to the corresponding Product Backlog item. The linking is required for all the various reporting mechanisms in the Conchango Scrum template on TFS.


Most of the time we have used Excel during Sprint Planning meetings since we tend to be adding quite a lot of items and using the query view in Team Explorer was tedious. Using the Task Board app is less tedious than Team Explorer but still not as easy as Excel. So you can still use Excel to rapidly enter Sprint Backlog items and then publish them back to TFS, but since you cannot link items in Excel they will not be connected to any Product Backlog items. You can then open the Task Board app and open the Orphaned Work Item section to drag and drop these Sprint Backlog items to their corresponding Product Backlog item.


So while this option does not provide a good option for Release Planning, it is one possible solution for Sprint Planning. Using the Task Board app can give the team a more tactile feeling during the process. Seeing item represented on the screen gives you more of an idea for the scope of a Sprint/Release.

I still like the interface provided by VersionOne for Release Planning. Not only does it provide an easy to use drag and drop interface, it provides feedback on capacity as you go (see a demo here).


So thanks again to Jeff for prompting me to take another look at the functionality in the Conchango Task Board application. Now if they could just rip off the features in VersionOne I could get down to only two applications!

Comfortably Scrum: Book Review for "Scrum and XP from the Trenches"

The book "Scrum and XP from the Tranches" by Henrik Kniberg was suggested reading for my Certified Scrum Master training course. You can download it for from from InfoQ and I highly suggest you do. It has been out for almost a year now so I am a little late coming across it and I really wish I had found it sooner. The book's format is great in that it is told totally from Henrik's point of view describing how his team adopted Scum (and some XP practices) at his company over one year. It does not have the same rhetoric as a few of the other popular Scrum books, but rather a basic outline of how they implemented the Scrum framework and the basic philosophy around each decision. He never claims that his process is the right way to do Scrum, but the one that worked best for his team. I found it realistic and pragmatic. It is a short read and goes very fast so with it being free you really can't go wrong with this one.

Comfortably Scrum: Is your company ready to be agile?

As I have posted in previous blog posts, adoption of Scrum (or any agile process) cannot be a development only effort. If done right, Scrum will have an effect on almost every department in your company that is involved in developing software. And if your company (or even just key parts of it) do not get on board, it can make for a painful process. So if you are thinking about possibly adopting Scrum, ask yourself the following questions to see how open you company might be:

1. Do key members of management buy-in to the agile concept? They do not need to understand it in its entirety, but they need to be open to the new (and sometimes radical) ideas it brings.
2. Do the other departments show interest in the agile concept? I have seen the most push back from QA and BA departments when adopting Scrum. Some of them see it as the developers wanting to "take over" some of their territory. It is sometimes a hard task to convince them this is is not taking over anything but sharing the effort across all departments as part of a cross functional team.
3. Does the nature of your business mandate processes that are counter to Scrum's? Many agile purists claim there is not such thing, but there are simply some businesses that would have a difficult time adopting Scrum because their way of doing business demands an approach in direct conflict with some of its ideals. Strict deadlines that cannot move, regulations that require comprehensive documentation, or a level of precision that requires a large amount of up front requirements gathering and system design are not impossible in Scrum, but might cause you to adapt it to the point of loosing the true benefits of the process.
4. Do you have a team of disciplined developers? This is something I talked about in another blog post. Scrum (and agile in general) is misconstrued as allowing developers to do whatever they feel like. In fact it is the exact opposite. Many developers have struggled coming from very structured shops that gave them a process to hide in and basically told them what to do. Scrum requires a developer to be cross functional and the processes themselves are meant to expose inefficiencies.
5. Does your infrastructure allow for cross functional teams? The best way to work in a Scrum team is to have them physically located together. I have worked in both situations where everyone was in the same room or a short distance away to having half the team in two other states. If you cannot be together physically, you will need some mechanisms to bridge the gap and allow easy collaboration between team members. Everyone knows I am a big TFS fan and I personally would not manage a diversely located team without it. Readily available conference calls, Live Meetings (WebEx or whatever), and instant messaging are a must for every member of the team. This does not just mean developers. BAs, QA resources, IT staff, and the users/stakeholders should all be as easy to collaborate with as the developer sitting next to me.

These are by far not all the questions to ask yourself, but they are some big ones that get the conversation started. I have heard agile experts even advise adopting agile practices without management knowing and slowly work up to involving them. In my experience that is a huge mistake. Moving to Scrum or any other agile methodology should be something the entire company works together on to make a clear and unanimous choice. There are definitely companies out there that are not yeat ready to adopt a process like Scrum and may never be able to. Scrum like any other software development process is not a silver bullet and is not meant for everyone.

Coming up next for the Comfortably Scrum series: Product Backlog Items.

Comfortably Scrum: Series Introduction

I have been presenting on Scrum and how I have implemented it processes using Team Foundation Server for the last year and almost every time I talk about it I run out of time. Both Scrum and TFS are complex entities and it is hard to talk about them both in one hour.

I am starting a new series of blog postings entitled "Comfortably Scrum" as a way to spend a little more time on a specific topic and do it justice. I eventually plan to accompany each blog post with a companion video.

I am currently working on the first post on gauging if your company is ready to adopt an agile process like Scrum.

More to come!