Building Your Own Process

April 22, 2012 — Posted by Al Shalloway

Continuing on with building your own process, I’m going to go through the forces I discussed last week and give an indication of when you want to pick one way to implement something versus the other.

If you haven’t read it already, you might want to start with Where to Begin Your Transition to Lean-Agile.  This article discusses many of the issues of starting to do (or as many prefer, be) Agile.  It is not always as simple as starting a pilot project with Agile - see How Successful Pilots Often Actually Hurt an Organization.

What team structure to use.  If you already have cross-functional teams, then you should definitely have your Agile process use them.  The biggest difference is that they will now certainly self-organize as well.  Virtually all Agile methods can use self-organizing cross-functional teams.  Some methods such as XP and Scrum, require them.  Others, such as Kanban do not. 

Cross-functional teams are teams that have all of the folks on them required to deliver functionality.  Sometimes organizations are hard-pressed to create teams of this nature because some people are required to work across teams due to special skills, subject matter expertise or knowledge of legacy code (amongst other potential reasons).  In this case, you are probably going to need to incorporate Kanban into the mix to at least manage the time of these folks.  A hybrid approach with almost cross-functional teams with Scrum and Kanban to manage these special folks is also possible.  Many folks prefer, in this case, just to start with Kanban.

Use flow or time-boxed forecasts. Whatever you do, you’ll want to check where you are on a regular basis.  However, you have the option of telling management what you expect to get done on a regular basis.  If you do this, you will use iterations.  At the beginning of each iteration you’ll spend a bit of time estimating what you think you can do over the next iteration (typically 2 weeks, but can be as short as 1 or as long as 4).  If you take this approach you should try to complete all of your work at the end of an iteration.  This has the advantage of somewhat forcing you to closure.  You can do this with Kanban (which can have iterations) or Scrum, which requires them (which they call Sprints).   If you chose to not plan ahead and try for closure at the end of the iteration, you must use Kanban as it does not require iterations.

A not necessarily good reason to use flow is if the team does not know how to break down their requirements into small (< 3 days) stories.  We think stories, just before they are worked on, should never be greater than 3 days.  But if you don’t know how to break them down, using iterations will be difficult, if not impossible.

Learning methods. All Agile methods use regular retrospectives to learn.  But there are other methods besides this.  In Scrum, retrospectives are done at the end of the sprint (iteration).  In Kanban, it’s done on a regular basis – for whenever it works for the team.  Another way of accelerating learning is to use explicit policies for one’s workflow.  This is a central practice in Kanban, and can be added to a Scrum team.  Explicit policies means that the team discusses, explicitly, what it is doing.  There is a lot of evidence that this accelerates learning.  However, this does require having an explicit workflow.  See the myth Explicit Policies Are Static, Hard to Change and/or Inflexible. We believe you should always have explicit policies about your workflow.

What to know before you start.  I highly suggest looking at Principles and Practices All Agile (including Scrum) Teams Should Know and Follow.  We believe that there is a base knowledge all teams should start with.  The idea of re-learning the last 15 years of Agile development seems wasteful. 

Alan Shalloway, CEO, Net Objectives

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban