Building a Snowman - A Federal Analogy

A couple of weeks ago in the DC area, we got quite a bit of snow. Being that there was snow, my three and half year old son and I decide to make a snowman.


We get dressed and go out and start making the snowman. I show him what I’m doing and how to make a snowman. He’s helping out a bit here and there and everything is fine for a little while.

He soon loses attention and decides he wants to play with the shovel, which is fine. He’s playing with a shovel and I’m making a snowman. Once he sees my snowball really take shape, he decides he wants his own snowball. I stop what I’m doing, make a snowball for him and show him what to do with it.

Soon my snowball gets larger and the boy wants me to stop my snowball and make his larger. He then decides he doesn’t like the way I roll my snowball and wants me to only pat the snow into the snowball. He then doesn’t like the way I pat it and wants me to pat it a specific way.

Eventually, he says it’s cold and wants to go back inside. So I wrap up the snowman, take a picture and we’re done.

Our happy snowman!

So what’s the point? As I was going over this in my head, I had a little laugh and realized that there are quite a few similarities between that experience and experiences in the Federal government. Now I wouldn’t be so condescending as to say it’s like working with a 3 year old; I’ve worked with and continue working with many sharp, skilled, and high functioning Feds. The similarities to the snowman exercise lie in the way the projects can get distracted and derailed. It’s the execution of the bureaucracy, governance, and politics that can cause the distractions to the projects. Note I say execution because the questions that the Feds want answered are fine. Things like identifying how much value has been delivered, is this project still viable, are the systems secured are all valid questions, the inefficiencies lie in the way the questions are posed and artifacts or evidence that is required/mandated to answer these questions.

Now back to the snowman, the point of this exercise wasn’t to build the snowman; I could have left the boy inside the house and built a super-snowman in half the time. The point is to enjoy the time with my son.

When working on a Federal project, is the true goal the stated goals of the project/program/organization?  It should be, but the nuance is to be able to work with the Feds and help define and direct the implementation of the vision towards actual project success. Along the way, it would be great for us Agile-ists to try to affect true Agile change in these organizations where we can.

An Outline for Scrum

I recently created a Scrum outline that some may find helpful. Enjoy:

Listed below is an outline for Scrum. This is meant to be used as a guide, the Scrum team is free to adjust and implement based upon team needs. The guiding ideas of the Agile Manifesto and 12 Agile principles should be followed when creating specifics for the Scrum team. Note that you can download the word version of this document here.

1. Roles
   
   1. Scrum Team
      
      1. Performs the work
         
      2. Creates their own tasks
         
      3. Pulls stories from the Product Backlog
         
      4. Owns the sprint backlog
         
      5. Provides estimates and commitments
         
   2. Product Owner
      
      1. Accountable for the product
         
      2. Owns the Product Backlog
         
      3. Prioritizes the Product Backlog
         
      4. Provides goals and vision
         
      5. Product Owner determines when to release
         
   3. Scrum Master
      
      1. Enforces process
         
      2. Prevents and remove impediments
         
      3. Tracks metrics
         
      4. Facilitates Daily Scrum
         

   
    

2. Scrum Board
   
   1. Sections for:
      
      1. Work waiting to be picked up
         
      2. Work in progress
         
      3. Work ready for review
         
      4. Work that is DONE
         
   2. Sprint burn down chart
      
   3. Project burn down chart
      
   4. List of impediments
      
   5. High visible in a public area
      
   6. Daily Scrum revolves around Scrum board
      
   7. Team interacts with Scrum board during Daily Scrum
      

   
    

3. Product
   
   1. Product Backlog
      
      1. List of all features/PBI/user stories for the product
         
      2. Can also contain bugs, technical pieces, and spikes
         
      3. Owned, maintained and prioritized by the product owner, thought team members can add items to the Product Backlog
         
   2. Sprint Backlog
      
      1. Prioritized list of features the team is developing during the iteration
         
      2. Sprint Backlog created by the team
         
         1. Items in Sprint Backlog pulled based on priority from the Product Backlog
            
         2. Represents the work that the team has committed to complete for the Sprint
            
   3. Roadmap
      
      1. Mapping of all Product Backlog item to a "timeline". This can be done by month, sprint, release, quarter, etc
         
      2. Product Owner provides the Roadmap content and prioritization, the Team provides the estimation
         
   4. Release
      
      1. Product Owner determines release
         
      2. A regular recurring release cycle is recommended
         

   
    

4. Meetings
   
   1. Daily Scrum
      
      1. 15 minutes max
         
      2. Each team member states:
         
         1. What I did since last Daily Scrum
            
         2. What I plan on doing today
            
         3. My impediments
            
         4. My work that needs to be reviewed
            
   2. Sprint Backlog Planning
      
      1. Product owner presents top priority items from the Product Backlog that are candidates for the upcoming Sprint
         
      2. Team uses planning poker to estimate each user story/item
         
      3. Stories that cannot be estimated upon can be converted to Spikes
         
      4. Team commits to a set of user stories/items for the Sprint
         
      5. Stories are either rank ordered or marked as high, medium, low (and optionally stretch) priority
         
      6. These items become the Sprint backlog
         
   3. Sprint Task Planning
      
      1. The team reviews each story and decomposes it into tasks
         
      2. Hours (Optional)
         
         1. Team provides estimated hours for tasks (optional)
            
         2. Team capacity should be # of available hours (should be a number less than 8 per resource, something between 4~6) and number of resources
            
         3. Take into account holidays, hours, and misc outages
            
         4. Take into account unplanned work
            
      3. Generally, work is pulled real time and not assigned during task planning
         
   4. Sprint Closeout / Review
      
      1. The team along, with the PO and Scrum Master, review the user stories/tasks/spikes
         
      2. Ensure each is done, a story is either done or not done
         
      3. Story done-ness is defined by the story acceptance criteria, not all tasks for a story need be completed for the story to be done
         
      4. Collect total story points completed (optionally actual hours as well)
         
      5. Note actual velocity and completion percentage
         
   5. Sprint Retrospectives
      
      1. Team reviews the process and discusses the things that have been working well and potential areas of improvement
         
      2. The Scrum Master and Scrum Team create and update the process norms for the team
         
   6. Meetings Techniques
      
      1. Meetings should have a clearly stated goal or desired result
         
      2. Meetings should be timeboxed
         
      3. A parking lot can be used to hold ideas that or of note, but not directly related to the meeting goals or desired outcomes
         

   
    

5. Estimation & Metrics
   
   1. Epics - a high level idea or theme that is comprised of user stories.
      
   2. User Stories
      
      1. Features that the team can estimated and decomposed into tasks
         
      2. Ideally in the form of "As a {user}, I want {feature} so that {value}."
         
      3. Each story has an acceptance criteria so that we know when the story is done
         
   3. Tasks
      
      1. Team decomposes user stories are decomposed into tasks
         
      2. Tasks are not assigned, rather they are pulled real time
         
      3. Team can provide hours estimates at the task level (optional)
         
   4. Spikes
      
      1. An allocation of time the team uses to investigate unknowns, research potential solutions, or addresses issues that are not stories or bugs
         
      2. A spike should have a goal
         
      3. At the end of the timebox, the team should be closer to addressing the goal of the spike
         
   5. Planning Poker
      
      1. Each team member provides estimates for user stories based upon a modified Fibonacci series
         
      2. As long as the team members are close in estimates, the team can proceed to the next user story
         
      3. If there is an inability to provide estimates or estimates differ by several orders of magnitude, then further discussions should occur for the story
         
   6. Story Points
      
      1. Story points are measure of the complexity of a story relative to previous stories
         
      2. This factors in both the amount of time it takes for the story and the difficulty of the story
         
   7. Velocity
      
      1. Planned velocity is the total number of story points that the team has committed for the iteration
         
      2. Actual velocity is the total number of story points that the team completed for the iteration
         
      3. Percentage completion is the actual velocity divided by the planned velocity
         
   8. Unplanned work – Unplanned work should be tracked. This can later be referenced in process improvement discussions.
      

   
    

6. Engineering
   
   1. Continuous Integration    - Critical for the rapid pace of Agile development
      
   2. Automated testing – automate testing as much as possible to help build quality into the process
      

   
    

Cross Functional Scrum Teams - A Basketball Analogy

I was recently involved in a discussion regarding the concept of cross functional Scrum teams.  The argument was presented that if you have a team with testers, BAs, and coders, does it make sense for testers to code, BAs to test, and coders to gather requirements?  This seems to go against what these individuals do well and ultimately truly want to do. I think those are fair points, but on a Scrum team, the team is really presented a goal, and they must determine how to get there. 

Let’s look at the game of basketball.  The goals of basketball are very simple, get the ball through a hoop and prevent your opponent from doing the same.  You have a team of 5 players on the floor and the team must figure out how to do this.  The traditional basketball team is made up of a center, a power forward, a small forward, a shooting guard, and a point guard.  These positions all have areas for which they are responsible.  The center and forwards play close to the basket and are responsible for rebounding and points near the hoop.  The point guard handles the ball and is the floor general.  The shooting guard has backcourt responsibilities and looks to create baskets from the outside, either through a jump shot or a drive to the basket.  This is an oversimplification, but close enough. 

With that being said, there are times when the situation in the game changes and the shooting guard may need to go inside and fight for rebounds.  The point guard may get trapped in the backcourt and need to pass to someone else to bring the ball up-court, the center may be left along at the top of the key and be forced to take jump shorts.  So essentially, the shooting guard is playing the role of the forward, someone else is taking the role of the point guard, and the center is taking the role of a shooting guard.  To accomplish the team goal of scoring and preventing the other team from scoring these real time adjustments and cross functionality must take place.

Similarly, on a Scrum team, the coders should be doing the coding, the BAs should be performing the analysis, and the testers should be testing, in general.  However, the team should have a goal and if to accomplish the goal, someone needs to help with the testing, or a developers needs to gather some requirements, or a BA should need to get into the code (gasp!), the team should be ready and willing to step in and fulfill the overall needs of the team.

 

(LeBron James - Cross functional NBA All Star)

High Value – Low Risk

I recently had an opportunity to participate as a panelist at a joint APLN PMI panel discussion on Agile project management.  It was a good discussion with Jesse Fewell creating an excellent post on this event.

During the course of the discussion, one of my fellow panelists suggested that when first implementing Scrum to tackle high value - high risk areas first.  This actually is in line with traditional Agile thinking where it is preferable to fail early rather than fail late.  Craig Larman, among others, have written in regards to this and I had supported this Agile line (and in many ways, I still support this line of thought … in theory).

However, in the course of this discussion I did disagree with my fellow panelist.  The key here is the context of this point is when first implementing Agile/Scrum.  As a consultant, I have seen when first introducing something new to an organization, many times there is very little, if any, room for failure.  In these cases, my recommendation is to identify high value - low risk targets and address those first.  By creating high value success early, this allows you to build creditability collateral. 

For a team (and organization) that is just learning a new process like Scrum, there can be confusion, nervous, and potentially resistance.  To ask a newly formed team or a team new to Scrum to implement and deliver on high value and high risk immediately compounds their unease and even further increases the risk.  If facing a high value – low risk target, the value can be just as great with a high probability of success, thus allowing the team to create a pattern of success that can help settle some of their initial fears and nerves.

Once this credibility collateral has been established and the team is performing at a high level, then as quickly as possible, shift to addressing high value – high risk work.  Hopefully at this point when the team does fail early, there will be enough credibility collateral built, along with organizational understanding of the process, to see these failings not as failings per se, but rather as a step in the process of iteratively delivering a solution.

---------
On a side note, pictures below from this event taken from JesseFewell.com.  Jesse is one of my fellow Xperts at Excella’s Agile Center of Excellence and he has been the key driver in creating some of the upcoming Agile PMI partnerships, including the PMI’s Agile Community of Practice.

One More Agile Blog V2.0 or "If you have sent me an email in recent months and I have not replied, here’s why……"

Welcome to the new (and hopefully improved) version of my blog, One More Agile Blog (now in version 2.0).

There are really two key changes.  The first is my blog URL is now http://www.onemoreagileblog.com/.  The second change is that I have changed the look of the site (which really just involved me changing the blog template).

Why the URL change?  To make a long story short, back in July I found out that my email provider, for some unknown reason, placed my BlogSpot blog URL on their URL blacklist.  This meant that any email coming into Excella’s email system with my blog URL in the body was automatically being blocked with us receiving no notification of this happening and being unable to retrieve these blocked emails.  This was extremely unfortunate since I have my blog URL in my email signature,  so this would have affected anyone replying to one of my emails.  I have lost and continue losing emails without knowing how many I have lost and who has been sending me emails.

If you’ve emailed me in the past month or two, there’s a strong chance that I did not get the email.  Please contact me at either my richard.cheng@excella.com (just make sure to not include my old blog URL) or richard.k.cheng@verizon.net (which does not have this issue).

With all that said, welcome to the new site.  More entries coming soon and this time I’ll strive to not have any month+ gaps in updates.

Common Agile Metrics

One of the questions that often arise is in regards to Agile metrics. What metrics should we capture for our Agile or Scrum teams? The answer varies based on the goals of the team, project, and organization. With that said, below are some of the most commonly used metrics for Scrum teams.

For teams using an iterative Agile process, like Scrum, the most common metrics revolve around story points. Commonly, Scrum iterations (sprints) are comprised of a set of user stories with each user story given an estimate in story points.

At the iteration level, the team commits to the stories they can complete in the iteration. The sum of the story points for these stories is the projected velocity for the iteration. Once the iteration is completed, the sum of the story points for all of the completed user stories is the team’s actual velocity for the iteration.

Teams may also decompose stories into tasks and these tasks can be assigned estimates as well. These estimates may be hours to complete, due date, or any other applicable unit of measure. This decomposition and task level estimation is optional; I recommend this level of granularity to be based upon the needs of the team and project.

Metrics for the Project

For a project that has a set beginning and end state, the project team can initially spend a bit of time creating all of the high level user stories and providing initial story point estimates. Once this is done, the team has an initial summary total of story points for the project.

Table 1 displays the metrics covered at the project level.

· Baseline Story Point represent the remaining story points at the start of the iteration

· Story Point Updates represent story points that are added or removed to the overall project during the iteration

· Story Points Completed represent the story points completed for the iteration

· Cumulative Story Points Delivered represent total story points delivered to date

· Story Points Remaining represent the remaining story points at the end of the iteration

· Ideal Pace represent the pacing of the project based upon the story points remaining and estimated velocity of the team. In this example, I show it as it was at the start of the project, however, this should be updated often. Updating at the end of each iteration is ideal.

Table 1 - Project Metrics

Iteration	Baseline Story Points	Story Point Updates	Story Points Completed	Cumulative Story Points Delivered	Story Points Remaining	Ideal Pace
0	1200	0	0	0	1200	1200
1	1200	196	60	60	1336	1125
2	1336	210	75	135	1471	1050
3	1471	22	67	202	1426	975
4	1426	-78	75	277	1273	900
5	1273	38	88	365	1223	825
6	1223	30	79	444	1174	750
7	1174	-106	82	526	986	675
8	986	22	90	616	918	600
9	918	-50	100	716	768	525
10	768	-10	92	808	666	450
11	666	25	95	903	596	375
12	596	40	98	1001	538	300
13	538	-30	108	1109	400	225
14	400	-40	119	1228	241	150
15	241	-23	105	1333	113	75
16	113	-15	98	1431	0	0

Figure 1 displays the Project Burn Up and Project Burn Down chart for the same project. The Burn Up line displays the story points completed. The Burn Down line displays story points remaining. For organization that are familiar with EVM type tracking, these Burn Up and Burn Down values can often be translated to EVM measures.

Figure 1 - Project Burn Up and Burn Down Chart

Metrics for the Iteration

The Iteration Burn Up and Iteration Burn Down chart is similar to the Project Burn Up and Project Burn Down charts, but the iteration chart tracks the work at an iteration level. In Figure 2 we are tracking the iteration based on hours completed and hours remaining. We can see that at the end of the iteration, there was 94 hours work of work that was not completed.

Figure 2 - Burn Up / Burn Down Chart in Hours

Metrics for Team Performance

For a Scrum team, some of the key goals include:

1. Achieving a high completion percentage (actual velocity / projected velocity),

2. Stabilizing velocity

3. Eventually increasing velocity (after 1 and 2)

Figure 3, Figure 4, and Table 2 display metrics captured from an actual Scrum team. These metrics are also useful for on-going teams or projects that do not have a set end state.

Figure 3 – Team Completion Percentage

Figure 4 - Measure of Velocity over Time

Table 2 - Team Statistics per Iteration

Measuring Business Initiatives and Value

To measure work on business initiatives, we can summarize story point allocation based on initiative (see Figure 4). This allows the business sponsor to identify where the effort was spent on their project.

Table 3 - Second Quarter Work Breakdown

	Story Points	Percentage
Foundational	78	22%
Maintenance	9	3%
Optimization	168	48%
New Product	98	28%

Additionally, the business teams can also assign business points, similar to story points. Whereas story points measure the complexity of a story to implement, the business points measure the business value of a story once it is implemented. This display of value and effort can help the business determine implementation priority and goals.

Table 4 - Second Quarter Work Breakdown

	Story Points	Business Points	Comment
Feature 1	40	8	High effort, lower value
Feature 2	20	13	High effort, decent value
Feature 3	4	8	Low effort, mid value
Feature 4	13	40	Mid effort, high value
Feature 5	5	20	Low effort, high value

Agile in the Federal Government

At the April APLN DC meeting, I had the honor of being on a panel for a round table discussion in regards to Agile in the Federal government.
The members of the panel included:

• Nate Carpenter of Pyxis Engineering
• Myself
• Thad Scheer owner of Sphere of Influence
• Dr. David Rico of Boeing

(Thanks to Jesse Fewell for the picture. See his blog entry for his thoughts on this session)
Overall, it was a good time. I use to work for Thad’s company (kind of, it’s a bit complicated) and it was great seeing Thad again. It is entirely possible that we may have closed down a bar or two back when we were working together.

Implementing Agile in the government space is tough. Obstacles include the existing oversight, budgeting and funding cycles and processes, general lack of Agile understanding on the Federal side, and conflicts of interest from the various consulting companies, prime and sub contractors, and government agencies. Agile helps you as a company or organization identify your goals and values and execute towards that end. Similarly, Agile does not solve your problems but rather exposes them. In government organizations, identification of clearly stated goals and values combined with exposing problems is something that will generally be met with obstacles.

However, it’s not all gloom and doom for Agile in the Federal government. In an August 2008 interview with CIO magazine, CIA CIO Al Tarasiuk stated “His team has also moved completely to agile project management methodologies…” Additionally, Dr. David Rico stated during our panel discussion that Boeing has standardized on Scrum.

At the team implementation level, Agile has a good chance of success and I am seeing that at my current client site. Since we control the team and with team acceptance of Agile, the Scrum Master / PM can shield the team from much of the organizational issues that may affect the team’s Agile implementation and performance. This will require more work from the Scrum Master. Many of the reports that will be asked to be generated and given may not naturally seem to fall within Agile practices. It will be up to the Scrum Master to identify the key metrics such reports want to capture and translate the Agile team metrics to metrics more familiar to others in the organization. Examples include translating burn up and burn down charts into EVM reports, iteration and product backlog can translate into Gantt charts, and end of iteration reviews and retrospectives and feed into status reports.

At the executive levels, expressing the values of Agile can be quite convincing to a sympathetic executive. The key is identifying and gaining access to an executive who is ready to hear a message about empowered, optimizing, evolving, value based delivery.

The middle tiers is the most difficult. The oversight and middle management levels can be heavy and if leaning an organization, this would most likely be spotlighted as places where leaning can take place. That combined with the conflicts of interest and personal interest that exists at these levels can make these layers quite problematic. Probably the most effective way to deal with this is for organizational support at higher level to effect certain Agile changes to take place at these layers.

For working Agile in the Federal government, I recommend the following:

• Choose your battles. There will be a lot that you will want to change and you will not be able to do it all overnight, so start small and pick your battles.
• Create creditability collateral. Demonstrate a pattern of success so that when the big battles do come, you will have the pattern of success to strengthen your position.
• Identify what is being asked. You may be asked to provide many reports, presentations, briefings, etc that may seem to be a lot of overhead or waste. I recommend identifying that the goals of these requests are and identifying if there is an Agile translation to the nuggets that these requests are trying to achieve.
• Lastly, good luck, you’re going to need it!

Shu, Ha, Ri with Alistair Cockburn

Yesterday, I had the chance to spend the day (actually 12 straight hours) with Alistair Cockburn. Excella’s Agile Center of Excellence held a private breakfast event featuring Alistair and he and I met with several clients later in the day as well. It was a great experience and great fun. Not only is Alistair extremely knowledgeable, but he’s a funny and nice fellow as well.

(Alistair and I after a long 12 hour day)

(Alistair with Excella’s OPM team in front of our Scrum wall. Note we are both pointing at the IMPEDIMENTS sign)

Yesterday provided much blogging material, but I will start with Shu, Ha, Ri.

During one of our client meetings yesterday, the topic of Shu, Ha, Ri came up, which Alistair describes in his book Agile Software Development (now in second edition as Agile Software Development: The Cooperative Game).

When Shu-Ha-Ri came up, Alistair asked me to describe it and I provided something along the lines of the following:

Shu, Ha, Ri, comes from Aikido (think Steven Segal in Above the Law, his only good movie …. other than Executive Decision, which barely counts considering he dies in the first 20 minutes … bonus material for blog, not in original statements). Shu, Ha, Ri roughly translates into learn, detach, transcend.

From the perspective of learning Agile (and really learning in general), Shu represents the first level of learning Agile. At this level, one learns a certain skill/technique and essentially mimics it. In the case of Scrum, one learns Scrum and then starts by implementing a set of Scrum based procedures; daily stand-ups, product and iteration backlog, Scrum Board, etc. At this point the Scrum student is learning and implementing the technique.

The next level of learning is Ha. At the Ha stage, one starts looking beyond their technique. For someone looking at Scrum, they realize that textbook Scrum doesn’t speak to areas such as project initiation, engineering practices, and testing techniques. One looks at other areas to broaden and deepen their skill sets.

The third level of learning is Ri. At the Ri stage, the focus is no longer on technique but more on outcomes. When presented objectives and goals, the practitioner doesn’t say they’re going to use a particular method to solve a problem, but rather the practitioner achieves the desired outcomes by applying the appropriate techniques from their repertoire needed for the specific situation to deliver the desired outcome.

After I gave my interpretation, I asked Alistair if I had it correct. I was happy to hear Alistair state that I had it correct and he said that he really liked my explanation of Ri, which wasn’t quite what he said. He then said he liked what I said about Ri better and is thinking about stealing it. Which makes me happy and will make my lawyer very happy when I put the lawsuit together (kidding!).

Overall, fun day.

To Do List = Personal Backlog

Wow, I have been very negligent in my blogging in recent weeks. I guess when you have a new baby and a 3 year old running around, it wrecks havoc on your free time. This means that no matter what I do, my to do list keeps growing bigger and bigger.

I've had "update blog" almost every day on my to do list, but like a good product owner, I have been constantly prioritizing and re-prioritizing my to do list. Though "update blog" is a task on my to do list, it seems to keep getting pushed closer to the bottom of the list, after tasks like "buy diapers", "do laundry", and "get some sleep".

When you think about it, this to do list is really a personal backlog. Also, since I am not running personal iterations, it's more like a backlog for an iteration-less process, maybe like Kanban.

And yes, I did say task and not user stories. Zero chance I'm writing full user stories on my personal backlog. Nor do I have owner, or reviewer, acceptance criteria on my backlog (though I'm sure my wife would like this in many of the tasks around the home). Also note that the only status is Done or Not Done.

Hmm, full user stories may be interesting:

• 
  
  As someone who is supposed to write on his blog, I really should write on my blog, so that the guys at work aren't like "Dude, what's up with you not updating your blog"
  • Acceptance Criteria: I'm not paying $20 dollars a week for missing all my blog entries (actually, we never did really implement that, which is a good thing)
    
  • Story Points: 13
    
  
  
• 
  
  As a sleep deprived adult about to go insane, I would like to get more sleep at night, so that I don't go postal at work
  • Acceptance Criteria: I wake up fresh and alive and ready to take over the world
    
  • Story Points: infinity
    
  
  

Actually, today I put together some notes in regards to an analogy between Agile and the sport of Mixed Martial Arts and so a real user story on my backlog is:

• 
  
  As a reader of my blog, I want a well-written blog entry that creates a compelling analogy between Agile and the sport of Mixed Martial Arts, so that I can be entertained for hours based on a single blog post….
  • Acceptance Criteria: Blog is on my blog site
    
  • Story Points: 8
    
  • Priority: Medium
    
  • 
    
    Due Date: COB 6/15 (I'm taking a 3 day weekend vacation starting tomorrow)

That's it for today. When you next see my blog entry, it may be my mixed martial arts entry, or the blog that I started weeks ago regarding my APLN DC panel discussion and still have not yet finished.

Agile Testing

A co-worker was recently asked “Who will be doing the system testing” on his project and this brought up the topic of Agile testing.  He sent an email asking “When doing a project using Agile and Scrum, how do you develop the system tests?  Do you script scenarios based on the stories?  The tasks?”

 

So in my reply, I was able to get a bit of a two for one deal out of it.  I was able to reply to his question and create a blog post as well.  Here is a paraphrased version of my reply:

----------------

“When doing a project using Agile and Scrum, how do you develop the system tests?  Do you script scenarios based on the stories?  The tasks? “

From the stand point of Agile engineering best practices, quality needs to be built into the system.  TDD is popular among the XP crowd.  Automated testing and continuous integration is key in Agile.  With the rapid pace of iterations, it is difficult to go back and manually test previously covered areas, so the automation of testing provides repeatable and repeated verification of correctness.

Using utilities to check for test coverage of code is helpful.  Sound testing at the engineering level is the first and best line of defense.  If something broken, stop the work until it is fixed.  Remember, a user story is not complete until it has been tested.  So yes, craft tests around the user stories, but also have the automated tests hit as many areas as possible.  Using tools such as nUnit for unit testing, Selenium for UI or interface tests, Fit/FitNess for acceptance tests, and LoadRunner for performance testing are all ideas in the automated test toolbox.  There will certainly be a bit of an engineering cost to implementing these tools, but I know there is research out there that does show that these engineering costs are paid back in savings in the quality of the code/project.

 

Specifically on this project, my thought is :

• Ensure the team has a responsible level of code coverage through unit testing

1. Consider using TDD (though I have not personally had great luck with it, but I’m no expert in it)

• For each story, design a responsible set of test scripts for the story.  Hopefully these scripts are tests that can be automated.

1. Work with the tester and the team to identify what responsible set of test scripts mean
2. Work with the tester and the team to identify how to (and who will) manually test the non-automated tests

“Who will be doing the system testing?” 

The question “Who will be doing the system testing?” is a bit confusing.  By system test, do we mean a traditional test of the overall system?  Does this question ask who will be creating the test scripts and/or who will be performing any of the manual testing?  In terms of who should be writing the test scripts, I think that answer varies, but it ultimately should most likely be a team effort.  It varies due to the specifics of the project, domain, and available resources.

In this case where there may only be one person devoted to testing, if this is a highly skilled person, they can own the testing strategy and create testing stories and strategies which the team (along with this person) can execute.  If the person is not able to fill that role, the team will need  to determine the test strategy and work with the testing resources to implement and execute the testing strategy.

The concept of having a person(s) coming in fresh at the end of a project (or even project cycle) to test seems ineffective.  In the past I have seen this as just an exercise in helping the tester understand the system being developed and how to use the system.  The tester may stumble upon on few defects  or issues here and there, but from cost benefits standpoint, the returns seems quite low.  Having resources that are integrated with the team and developing tests iteratively with the team seems ultimately more efficient.

I’m back!

In my last blog, I had mentioned I was going to be taking a little break with the upcoming birth of boy#2 and on April 20th 2009, we were blessed with Lucien Javier Cheng!

Mommy, Boy#1 (Simon Maxwell Cheng, now 3), and baby Lucien are all doing well.  Daddy (me) is being driven a bit insane, but also doing well.

I’ve taken a bit of a break from some of my workload (including this blog), but I am now ready (or relatively ready) to jump back into the fire.  My next blog coming up shortly!

Taking a Short Break

Sorry for the gaps in posts, things have been a bit hectic as of late, baby boy #2 is going to be here any day now. Actually, we thought he was coming Wednesday, and then again on Friday, and I'm sure that we are delivering tomorrow.

So, it may be a little bit before my next post. I do have some topics on my mind (aside from freaking out about the new baby almost being here). These include Agile in the Federal Government, which I recently had a chance to discuss as part of an "expert" panel at the April APLN DC meeting. Also, my thoughts with dealing with under-performers on Agile teams.

Anyway, that's it for now, hopefully I'll be posting thoughts again very soon.

You’re either on the team or you’re not…

Just a little rant today:

 

Scrum has 3 roles.  Scrum Master, Product Owner, and the Team.  I believe in a team of doers and performers (probably the same thing). 

 

I, in general, don’t believe in putting a data modeler on a team, or an architect on a team, or any specialized role on a team.  It’s not to say I don’t believe in having a data modeler or architect on the team, as long as they can view themselves as a member of the team willing to do work and get work done.

 

I believe the team needs a team data modeler if the team says, “These data relationships are pretty complex, we really do need a data modeler”, then we start talking about a data modeler (or architect, or whatever).  However, in many cases, the team members can really model their own data or architect their own systems.

 

Often, we use a DBA service, or operations service.  They provide a service to the team, but not a part of the team.

 

There may be some exceptions to the rule.  When you want to create an organizational consistency, you may have an enterprise architect or data architect, but they usually work with the team as a guide or provide service.  If you’re on the team, you’re on the team, skin in and all.

 

Anyways, just a bit of a minor rant today, no real coherent thought to it.

Using planning poker to ensure common understanding

 

One of the techniques that many Agilists have been embracing is using planning poker to help the team estimate and plan for an iteration. The focus of today’s blog is that one of the nice benefits of planning poker is helping ensure a common understanding of the work (story) at a team level.

Brief Introduction to Planning Poker

 

Planning poker is generally used during the team iteration planning meeting to help the team create estimates for stories (feature requests). Each team member has as set of cards that are numbered based on a modified Fibonacci sequence (?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity).

 

After each story is presented to the team, there may be a few questions regarding the story. The time spent asking and addressing these questions should be kept as brief as possible. At this point, this is not a design discussion, the questions should only relate to helping the team member form a rough order of magnitude estimate.

 

After the story is presented, all team members display their cards simultaneously. Once all the estimates are shown, the team can determine if there is a general consensus or agreement to the estimate for the story.

Common Understanding

 

If all of the estimates are roughly in the same neighborhood, then the team is ok. You can optionally ask the highest and lowest estimates on what their thoughts are, but if they are in the same ballpark as the rest of the team, it is usually relatively easy to come to an agreement.

Example, if the ranges are a 3, a couple of 5s and several 8s, not a big deal. Have the 3 explain their thought and you’ll find they’re probably willing to go up on their estimate.

 

Note when everyone in the same ballpark, do NOT spend a lot of time discussing the story, you’re done estimating the story, go on to estimating the next story (or tasking the story, if your team tasks after each story, which I would NOT recommend).

 

However, if there is a large gap in estimates, this is where you get the good stuff. Say most of the team is around a 5, but one person has a 20, then something’s going on. Either the 20 does not have a correct understanding of the story (or what it takes to implement the story), or the 20 knows something the others do not. Either way, this requires discussion.

 

Examples 1 – technical implementation:

The story is “implement role based security model”. Most of the team throws an 8, however one person throws a 40. Discussion is held and the people throwing the 8 believe they can leverage an existing security model the company has. However, the 40 knows that the legacy security model is outdated and does not come close to supporting the needs of this project. The ensuing discussion helps bring this to light and the team re-throws based on this new knowledge.

 

Example 2 – Story understanding:

The story is “Display Custom Images in System”. Several of the developers throw a 100 and the business analysts throw an 8. Each is surprised at the other’s estimates. During the discussion, turns out the developers thought that the system needed the ability to actually create and save images while the true requirement was that the system only needed to display an image from a specified location.

 

The key point of this blog is that using this technique should allow the team to quickly breeze through estimating stories where there is a general consensus on the size of the story and ensuring there is a common understanding in situations where there is a large gap in estimates.

-------------------------

(Note that the common understanding is just one of the benefits of planning poker. There are also major benefits in terms of velocity and using velocity to help plan team capacity, but more on that in a future blog.)

Scrum Artifacts

I was recently asked to put together a list of Scrum artifacts, so I figured that this would be a good topic for my latest blog entry. Some of this will just be a Scrum 101 refresher for those familiar with Scrum, but this may be useful for many.


A couple of notes:

· The list below represents a possible/typical implementation of Scrum. One does not have to follow these exact items to implement Scrum.

· Many of the items described below are implementation details of Scrum, but not specific artifacts prescribed by Scrum

In Ken Schwaber’s Agile Project Management with Scrum, the only items he has listed as Scrum Artifacts are the Product Backlog, the Sprint (Iteration) Backlog, and Increments of Potentially Shippable Product Functionality.

· And yes, I know, many items on my list are not really artifacts. To make things easier artifacts presented in black, general concepts in blue, and meetings in red.


----------------------

Epics / User Stories / Tasks


User Stories – A feature that can be estimated.


Epic – A feature that cannot be reasonably estimated due to its complexity, scope or number of unknown issues.


Tasks – The work needed to complete a User Story.


Epics can usually be broken down into User Stories. User Stories can be broken down into Tasks.


Planning


Product Backlog – A list of the Epics and User Stories for the entire Project / Product. This list is prioritized by the Product Owner.


Sprint Backlog – A list of the Epics, User Stories, and Tasks that the team has committed to completing for the current iteration. This is created during the Iteration Planning Meeting.


Story Points – Units of estimation for User Stories. Usually based on a modified Fibonacci sequence.


Planning Poker – A method of estimation used in Iteration Planning. Each team member is given a set of card representing story points. For each user story, team members display a card representing their estimates. The team discusses the results and comes to a consensus on the estimation.


Iteration Planning Meeting – At the beginning of each iteration, the Scrum team meets to plan work for the iteration. The first part of the meeting involves the team working with the Product Owner in reviewing the prioritized Product Backlog and putting Story Points for each User Story. The team then commits to a certain number of User Stories for the iteration. The second portion of the iteration is typically used by the team to create a list of Tasks for each User Story in the iteration.


Tracking


Project Board – This can be a physical board, a virtual board, or both. The board is usually placed in a visible location and presents the status of the iteration (and sometimes the entire project). The board usually contains an area for Work in Waiting, Work In Progress, Completed Work, and Verified Work. Other items that can be shown on the board include (but not limited to) a team calendar, burn down charts, and list of impediments.


Daily Scrum Meeting – A brief (15 minute) daily STAND UP meeting in which each team member gives a brief status up. This typically is limited to:

· What have I done since the last Scrum meeting.

· What I am planning to do today.

· List any blockers/impediments I have

· List any items I have ready for review

This meeting is typically held in front of the Project Board and the team members should update their tasks on the board during the meeting. Only team members should present during the meeting and all team members (barring physical considerations, such as a bad back or being very pregnant) should be standing the entire meeting. Standing meetings tend to not go very long.


Iteration Burn Down Chart – A graph displaying the amount of work completed and amount of work remaining for an iteration.


Project Burn Down Chart – A graph displaying work completed and work remaining in the project.


Team Velocity – The amount of story points a team has completed or can complete in an iteration.


Review


Iteration Review Meeting – Held at the end of an iteration, the Iteration Review allows the Product Owner, and potentially stakeholders and other interested parties, to review the deliverables for the iteration. All deliverables should be fully tested, defect free, ready to ship increments of functionality.


Team Retrospective Meeting – Held at the end of an iteration, the retrospective meeting typically allows the team members to discuss what has been working well, what has not been working well, and discuss any ideas for improvements or changes to the process.

A False Measure of Success …. Revisited

Today I received an unexpected email:

Hi Richard,

Not sure if you will remember me, but we spoke during the agile 2005 experience report selection process about your experience report. We ended up selecting your submission and you went on to write a paper ... and I am currently using the paper in a masters level course on agile methods at Oxford. The students are expected to analyse the case, and I know some of them might be keen to ask you some additional questions. Would you be open to that? I don't expect it will be too time-consuming, and it might be kind of interesting.

Anyway, I do hope that all is well in your world.

Cheers,

Angela Martin

Lecturer, Department of Computer Science The University of Waikato, New Zealand

I am quite honored to have Angela choose my paper as part of her master’s level course at Oxford (assuming the topic is not “Examples of poorly written articles”). I am also happy to hear that there is a master’s level course on agile methods at Oxford.

The article, titled A False Measure of Success, was something I wrote in 2005 for an experience report and was the basis for a presentation at the Agile 2005 Conference. In re-reading my article, the general message of the article is still pretty good. The heart of the article is really about a disconnect within a company in recognizing business needs and technology goals. Though technology goals were met, it came at a cost to the business needs. Instead of being partners in a solution, technology dictated the solution to business. Interesting stuff.

On the downside, also in re-reading the article, I realized that I might have gone into a bit of a tangent when I started addressing some Agile specific thoughts. I also realize that the longer development timeline does not quite look that bad compared to other projects I have worked since the article was written. But worst of all, who let all those grammatical errors through on a published paper (I blame my two editors .... myself and my wife). ARGHHHHH!!!!!!!

Certified Scrum Master .... the Big Lie!

At last night's APLN DC meeting, we were fortunate enough to have Scott Ambler present his talk on Scaling Agile Software Development: Reality over Rhetoric. Overall it was a good presentation with some nice takeaways. One thing that was noticeable was Scott's views on Scrum, CSM, Ken Schwaber. I will save most of these topics for future blogs, however I will address Scott's view on the 2 day Certified Scrum Master course.

Scott believes that the 2 day CSM course is a scam, a big lie, complete shenanigans. He believes that any professional should be ashamed if they put CSM in their email tags or business cards. And truth be told, I agree with him.

To take a 2 day course and, with no pre-qualifications, no exam, no peer review, no kind of validation or verification at all, become a Certified Scrum MASTER is deficient. Armed with only this 2 day course, one is most certainly NOT a master and is most likely NOT ready to implement Scrum without additional coaching/mentoring/help. We really should call the class what it is, a 2 day boot camp introducing Scrum.

The course itself is generally an excellent course, but one should understand what it does. The class helps the student understand the meaning of Agile and Scrum. It helps the student shift their mindset from a traditional/PMI/waterfall/EVM (EVM, one of the biggest LIES in he industry, definitely more on that in a future blog) base to an Agile/iterative/value/delivery mindset. It provides an overview of how to do Scrum and a general starting point on Scrum. For those already using Scrum or familiar with Scrum, it helps them walk through some of their thoughts, problems, and ideas. Hopefully by the end of the class, the student will be armed with some knowledge of how to implement Scrum, and more importantly, what it means to implement Scrum.

Scrum provides good process, artifacts, tools, foundation, and framework, but there are quite a few implementation details that need to be worked out and tailored to the environment. The actual implementation is quite tricky. It requires experience, expertise, and intelligence. Most people will need help if they hope to succeed just at the project level. To tackle it at an organizational level becomes an even greater challenge.

So really, understand that not all CSM's are created equal. There are some great ones out there and there are some who just had $1500 in their pockets and 2 free days to kill.

Empowered Optimizing Evolving Value Delivery?!?!?!

In my last blog, I stated that a Scrum Master that truly understands Scrum attempts to create "...a process /atmosphere of empowered optimizing evolving value delivery". When you say it out loud, it does sound like a bunch of buzzwords strung together, like leveraged synergies or synergized leverages. However, honestly, it does mean something.

Empowered - The process should be empowering. The Scrum process is not one where the team is treated like a bunch of mushrooms (kept in the dark and fed, ummm, dung), but rather it should be an open transparent atmosphere. It's a atmosphere where the team is not ordered and micromanaged, but rather an atmosphere where goals are set forth for the team and the team is empowered to do what they do best in achieving these goals.

Optimizing - The team is constantly look at what they are doing and looking to improve and become more effective. Looking at velocity charts and burns down charts, identifying patterns and cause and effect relationships. These things the Scrum Master works with the team to identify and optimize.

Evolving - Similar to optimizing, but grander. Optimizing is tweaking and improving, evolving is deeper, it is questioning base concepts and accepted process and questioning the value and delivery. It is a team feeling optimized and hitting a plateau, then self reflecting and determining what can be done fundamentally different and better.

Value - Not only having a prioritized product backlog, but ensuring the priority is accurate. It is truly understanding what your company / team / project mission is, identifying where the value lies, and using your resources to work on the value. On my last team, we did something pretty interesting. Once our Scrum team had worked together for awhile and there was a sense of team maturity and safety, we tried having value estimation meetings. Similar to a backlog story points estimation meeting, however instead of effort for points, we started addressing value points. How much value would each feature request deliver relative to each other. Turned out to be a great exercise, but the key was that a sense of safety had to be there for the exercise to truly be of value.

Delivery - This is key. Without delivery, all of the above is just a bunch of co-worker sitting around signing Kumbaya. By delivery, I mean actual working software (assuming your team is ultimately producing software). For example, requirements in themselves have no business value (unless you are in the business of selling/producing requirements, and in that case I have a bone to pick with you as well), rather it is a tool/artifact/side effect of producing software. If that same software can be just as responsibly made without those requirements, then are the requirements truly needed? Now, one common misconception is that Agile states no requirements, which is not true. Often it is more the form and standards in which requirements must be made and applied with which Agile has conflict. Anyway, requirements aren't the point, the point is that delivery is key.

Ok, so I hope I have convinced you that I did not just string together a bunch of non-sense industry words when I said empowered optimizing evolving value delivery. Now, I'm off to synergize my leverages.....

The Key Quality of a ScrumMaster

I recently met with an executive who is planning to pilot a Scrum team at his company. One of the questions that he asked was what where the qualities one should look for in a ScrumMaster. Most of the answers I gave him where consistent with an article Mike Cohn posted regarding this topic (btw, excellent article).

After giving it some thought, I think the one KEY quality of a good ScrumMaster is that they must get "it". What I mean by that is that they must really know the goals of what Scrum is trying to do and and achieve. Agile and Scrum is not about learning a set of rules and processes and then following some cookie cutter method of implementation, rather it is a set of ideas, principals, and goals that are to be achieved. And by achieved, I don't mean just achieved by the team delivering value, but also by the ScrumMaster working with the team and the company in forging a process /atmosphere of empowered optimizing evolving value delivery. To some people, those last five words may seem to be just a bunch of keywords strung together, but I think a ScrumMaster who gets it understands what I just wrote.

At my last client engagement, the ScrumMasters of the company pretty much got it. There were slight difference in implementation details, but everyone was working towards the same goals and optimizing their teams around a company culture and vision into delivery. They weren't following process for process sake or because some book told them to, but they were trying to identify where the values and efficiencies were and how to properly leverage them.

When a ScrumMaster does not get it, you have issues. Many middle managers tend to micro manage or task and order their teams. New ScrumMasters who came up as developers may have a hard time letting go of the tech side and may get too involved or prescriptive in dealing with their tech teams. ScrumMasters with a PMI/PMBOK background may try to implement Scrum with too much rigidity and process. These are signs that these ScrumMasters may not yet fully get it.

For all ScrumMasters out there, that a step back from your Scrum boards (assuming you are using Scrum boards) and think about this: Are your processes really following the heart of what Scrum and Agile should be bringing to you, your teams, and your company?

As a side note, once you get it, your team gets it, and everyone is firing on all cylinders, the job of the ScrumMaster becomes one of the easiest jobs in the world. Good luck getting to that point!

Can I be a Scrum Master and a Developer.....

Can I be a Scrum Master and a developer (or business owner or business analyst or whatever)? Sure, um... yes... um... maybe......


Years ago, I had taken a Certified Scrum Master training course that was that was given by Ken Schwaber (who taught the first 2 days and Mike Cohn taught on the third).

As Ken was defining the role of the Scrum Master as one who removes impediments, empowers the team, ensures process, enforces the Scrum rules, etc…, I started thinking “was that all they did?”. Starting out as a developer and at that time being a Project Manager who would still get hands on in the code and architecture, I asked Ken if a Scrum Master could also be an active team member. Ken’s answer was something along the lines of “no”. That did not seem to make sense to me and he and I ultimately disagreed over this point.

Sometime later, I found myself working on a small team (3 ~4 people) developing software. I was the Scrum Master as well as a pseudo architect and a key hands on developer. What I had come to realize is that I spent the vast majority of my time coding and everything I was doing was clouded from that perspective. In my role as Scrum Master, I found myself using the position to drive things from the perspective of a developer. Instead of helping the team focus on delivering value and working with the product owner from that standpoint, I noticed myself addressing the product owner as a developer focusing on meeting development deadlines and telling the product owner what features they could and could not have versus really allowing the product owner to really define the features they needed and valued. Once I started noticing this behavior, I was able to address it …. more or less. There was a constant struggle between the Scrum Master hat and the developer hat and it was at that point that I started really seeing what Ken was saying.

Since then, the vast majority of my engagements have been as a Scrum Master. In most cases, I did wear the Scrum Master hat and often used my experience and expertise in other areas to help the business teams, technical or operations teams in their respective areas. Most of the time it worked out pretty well. The times where it is more difficult is when I become heavily involved in details and implementation and started taking ownership of ideas or deliverables that the lines get a bit blurred. That’s not to say it’s always a bad thing, but in some cases it does have effect on being an effective and fair Scrum Master.

So can someone be a Scrum Master as well as something else? Ken said “no”. I say, in a textbook world it’s not ideal. However, real world situations may dictate differently, so keep an eye on your perspective. Are you being a fair and effective Scrum Master if you are doing something else? If not, what can you do to fix it? Remember, Scrum does not fix your problems but rather it exposes it and if being both a Scrum Master and something else becomes an unmanageable problem that should be listed as an impediment and dealt with.

Why another Agile blog?

The answer is simple enough, I don't want to lose $20 a week.

As a bit of background, my name is Richard Cheng and a little over 2 years ago I joined Excella Consulting. At the time I joined Excella, I already had my PMP certification and also received my CSM certification as well and had actually managed several Agile'ish and Scrum'ish projects.

During the interviewing process with Excella, I expressed the ideas that I really liked in the Agile space and how I think an iterative, collaborative, empowing approach to developing software was ultimately, the right way to not only run software, but in many ways to approach business. These thoughts and ideas really meshed well with the powers to be at Excella and it's been a beautiful relationship ever since (says the optimist, the pessimist would say thus far).

So what does that have to do with an Agile blog and $20? Ok, I'm getting there. So Excella recently created an Agile Center of Excellence, which I lead, to go along with its current Project Management Center of Excellence (lead by Jesse Fewell) and its Microsoft Center of Excellence (led by Scott Lock). So, the three of us had developed some key areas and goals that each of our CoE's should target. One of the side notes that came out of this was that we really should each have our own blobs. Now, I've been wanting to create an agile blog for years, but ultimately for a variety of reasons (most notably, sloth) I had not. So with this in mind, Jesse and I decided to make this interesting and lay out a friendly wager. Anyone of us who does not post at least 1 blog a week must throw in $20 into the missed blog pot. There you go, that's the story.

Now Jesse Fewell (http://www.jessefewell.com/) and Scott Lock (http://geekswithblogs.net/slock/) already have a head start, but in about 5 minutes, Blog #1 will officially be in the can.

As a side note, one may note that this entry has little to do with Agile, but there's plenty more coming. Next Blog topic will most likely be "Scrum But".