By Josh Roberts | September 7, 2014 | 0 Comment
Last week we held a Retrospective for the August iteration of our Agile/Lean Transformation. To kick things off, I asked them to share one word that described how they felt about the transformation to date. A few of the words that stood out were Anxious and Stalled; this was coming from some of the longest running teams. They are ready to take the next step.
As we discussed in the post Let’s Groom Our Backlog, getting our business partners engaged is the next major milestone in our transformation roadmap. Playing the role of a Product/Backlog Owner, the business will help us prioritize our backlog, understand business value, decompose work, and provide feedback. These are all key inputs into an Agile Team.
Our goals for the September iteration of our Transformation Scrum are aimed at taking this next step. See picture below from our Transformation Board.
Our primary goal is to assign and educate Product/Backlog Owners for 7 of our teams. We are also going to be discussing how to organize/staff our Agile teams. And, finally, mapping out our ITSM and ALM business processes in support of the upcoming ALM tool selection. These actions are all pre-requisites for moving to Agile Teams.
So what is an Agile Team? As I have said before, we will be using Agile practices (i.e. Scrum) at the team level to promote cross-functional teaming and iterative development. Below are some of the key Agile principles.
If these principles sound a lot like Kanban, they should! Both Agile and Lean principles originate from the work of Edward Deming. When we introduce Scrum, the key differences will be to decompose our Portfolio Kanban boards into Stories/Tasks and time-boxing our delivery via 2 week iterations.
The Scrum framework also prescribes a set of team practices and roles. The three roles are Product Owner, ScrumMaster, and Team. In the software development world, the cross-functional team generally consists of Developers, Business Analysts, and Quality Analysts, but the practices can be applied to any cross-functional team.
As we design our organization for Agile teams, it will be these roles that we consider. Once we have these role established, we can move our Kanban into two week iterations. This will help keep the entire organization synchronized and releasing on a cadence.
This past week we attended a timely webinar where Al Shalloway discussed how to apply Lean-Kanban at scale to manage software initiatives more effectively. It was a good reminder of where we are headed and what we have achieved. Something that caught the groups attention was the term Scrumban.
Scrumban builds on the Scrum framework by helping teams visualize their Stories/Tasks on a Kanban board. With a focus on delivering Stories, WIP Limits are applied for the different stages of Development work (Design, Code, Unit Test, System Test, etc). Like at the portfolio level, Kanban helps the team with their flow of work.
We have built a solid foundation for our Agile Teams and Scrumban is next!