Walls coming Down

This last month we have taken down around 100 personal cubes and replaced them with team pods. 9 pods and counting. Here are some before and after pictures. Pretty cool.


Wave 1 of Agile Rollout Started

As I promised, I would start blogging about the Agile rollout I am leading within my organization and describe how things are going so that others can learn just as I have learned from many others that have gone through the same experience.

The last two weeks was everything I thought it would have been. It included lots of excitement a few fears and everything in-between. Our scope of the first rollout was 120 people involved in 10-20 projects with all kinds of critical dates to other organizations. We also added 40 managers, some from my organization and some from other parts so that they can understand the change.

Managers were introduced to basic and advanced agile principals and practices, scrum as a mechanism for implementing team level software agility, agile technical and quality practices and the Agile Release Train as a means to provide strategic alignment and visibility across the organization. Teams were trained on similar topics, but focused on the Agile process called Scrum. Teams learned about backlogs, sprints, roles and how it will be applied at ISG.

 In addition to training, 14 scrum teams built “Big Visible Informational Radiators” that are posted around the buildings that show their daily status and objectives of the next four weeks. These BVIR’s will serve as a communication means to the organization. These teams are not alone in learning Agile and are supported by two highly experienced qualified coaches to answer questions and help ensure objectives are being met.

Looking forward, we will monitor the status of these 14 teams and make adjustments that will be applied to future team rollouts. In addition to monitoring status and planning for the next wave, I will travel to Europe to engage more managers and teams on the model we are applying.

 As for my retro on the first rollout:

Worked well:

  • Having everyone in one room rather than doing training in small groups
  • Including everyone that is working on the same system
  • Creating the teams ahead of time
  • Having coaches on site so that they can help in breakout sessions
  • Training the managers before the teams were trained so that they can support their people
  • Having managers and directors talk before the training explaining how they support this initiative


  • Making sure food showed up on time
  • Ordering rolling white boards for each team so that they could use them for task boards
  • Collected all of the critical dates and made them visible to all team members so that it would help with sprint planning
  • Met with coaches to give them more context so that it could be applied during training

 Overall, I thought it went great and have received compliments. However, here is no real end to this Agile endeavor where execution will be flawless, or even “good enough.” I have entered a new Agile state where change is the norm, rather than the exception. Agile is not a destination, but rather a journey and I look forward to this journey we are on.

 Take a look at the video from wave 1.

Marshmallow Challenge

Last week I played the Marshmallow Challenge with the Program Manager in my area. Each month we have a department meeting and I asked for 30 minutes to conduct the PM challenge. I did not tell anyone what the challenge was because I assume they would go and research to get a leg up.

My goal was to get them to think about doing things more like scrum rather than the traditional waterfall process that they are use to.

So what I did was put all of the pieces into a yellow folder and then described the rules to them. From there I set up a timer and told them that the highest structure would win a prize.

At the end, each team tried to put the marshmallow on the top with about 3 minutes remaining and all 3 of the teams had no standing structure.

If you are looking for a fun game to help the learning of Agile I would strongly suggest the Marshmallow Challenge!

This slideshow requires JavaScript.

Day 36 – Time to Start Regression Testing

Here is what our board looks like today. DONE!!! Now the painful part happens; regression testing. Since we have maybe 10% code coverage we have to complete 100’s of manual test cases prior to shipping in July.

Each day a between tomorrow and July we will review what defects were found and make a decision whether we want to fix it or not. Ideally we will find nothing and ship this version, but most likely there will be a few defects found that will require us to fix.

Kanban Board – Day 11 – 15

This last week had its highlights and challenges. I’d thought I’d go ahead and share what those moments were. Here were the highlights:

  • Documented what we thought our WIP’s were for each column. This is really tuff because more than half of our team is offsite. But I will figure out a way to fix this.
  • Prioritized and aligned our work with resources. This helped us make sure the most important things had the right number of people on it.
  • Started discussing where our bottleneck were.


  • We missed a critical milestone by 2 days that caused concern in our stakeholders and teams performance. This really makes me mad because the team is doing great, but this little miss creates big problems for me.
  • Having a hard time pulling metrics from our system (Jira/Greenhopper). Today it took me an hour to pull a cumulative flow diagram. Very disappointing.
  • Cards kept moving from done to testing because defects were found. Right now we only have 5-10% code coverage so things are really fragile.

The one thing that got me super pumped was the customer team is going to start an upstream kanban board because they see the value the downstream board has created. The board should be up by this week. Be prepared to see pictures of that.

Overall, the board has been great and there has been great conversations started and problems fixed.

This slideshow requires JavaScript.

Day 3-5 Kanban Board

That last 3 days have been very productive. Here is what we have created:

  • Created avatars for each person so it was easy to see what people are working on. (One small problem is that we have half of our scrum team in India, so I will have to tackle the problem soon)
  • Created some classes of services. The color of the cards represent the class of service
  • Created the value stream columns
  • Had our first “walk the wall” daily standup


Had lots of questions about:

  • What the “rules” are for moving cards from one state to the other.
  • Had questions about how many cards could be in each state
  • How many cards can one person be working on
  • If something is moved to done and then a defect is detected later, does the card get moved back

Here what we have settled on for our columns (working backwards):

  • Production
  • Done – Not in Production
  • Testing / Defect Fixing
  • Ready for Test
  • Development
  • Analysis / Design / Requirements
  • Ready for Development
  • Stories Created
  • Themes (class of services)
  • Backlog


So next week I will work with the team to identify policies for moving cards and creating WIP limits.

In general, it feels like we have too many things in progress and not getting things moved to done.

However, it is still better then what we were doing before.

Lean Software & Systems Consortium Conference

The Lean Software & Systems Consortium Conference has inspired me to start a blog about my road from Waterfall to Agile. On Monday I plan to create a Kanban board.  

 Here were my takeaways from the conference: 

1. Make Work Visible
– In my organization we have all of our worked stored in a web-based system. I think this makes it hard for everyone to see what we are working on which prevents questions and conversations from happening. @cmshinkle ‘s presentation really helped me see this. I really liked the 10 foot 3 second rule. You should be able to look at a board and see where there are problems within 3 seconds
2.  Value Stream Mapping
– Waste is not always in the development organization. I think mapping out how work gets into development, within development and then out of development would give everyone more visibility.
– Assigning Work In Progress (WIP) limits would make sure there is a steady flow.
– Developing metrics and policies
3. What is Kanban
– It is all about setting up a flow and then setting limits. Some of our problems is we get too much started and then we don’t finish anything. Kanban is just another set of tools, just like Scrum is.
Lean Software & Systems Consortium Conference 2010

Favorite Quote:

Metrics are like a lamp-post for a drunk, it provide illumination and support.