SCRUM and Kanban (as applied to software development) are different. Proponents of the two drift from staunch opposition to declaring Kanban as a special case of Scrum.
I have been practising and coaching Scrum for a number of years and I delight in the effect it has on project teams. While I practice Scrum I find that Lean Thinking can both help me communicate Scrum and help teams to become more effective in applying Scrum. This way of thinking led to me becoming interested in Kanban a year or so ago since when I’ve being most concerned with where I ought to recommend Scrum and where Kanban.
Recently I have spent time with maintenance groups for whom Scrum would be a poor fit. Kanban offered me an alternative when the client was leaning towards a ScrumBut implementation.
There are some fundamental differences between early project / product development work and the later stages and I don’t see this as a problem. Toyota themselves hold two separate approaches. The Toyota Production System (TPS) is the most widely known Lean Manufacturing implementation. This is the world of work cells, standardised work, Kanban boards and Andon lights. However, when Toyota want to create something new they use the Toyota Product Development System. This approach focuses on a chief engineer holding a vision and rallying a team around him. High bandwidth communication, discovery and experimentation are the order of the day.
So back in a software development context Scrum was designed to manage uncertainty and complexity, to foster high band width communication and seems a valuable fit for early development.
Corey Ladas in his ScrumBan Book declares the following Axiom for applying his application of Lean to software development
Axiom 2: It is possible to develop any value adding increment in a continuous flow from requirement to deployment
Corey makes it clear as he progresses that this well defined workflow is critical to his desired approach. In a new development that workflow is often not known and usually not linear. Rather the team swarm over the requirement often returning to the customer for feedback before offering a completed deployable feature.
My suggestion is this, Scrum is a powerful approach to managing uncertainty as well as being a supportive environment for building a team. I believe that one goal of product development should be to reduce the uncertainty and evolve the workflow. As adding features becomes more straightforward we may find that we are in a state akin to production and can take advantage of a Kanban approach to further optimise for reduced cycle time, increased throughput and just in time scheduling.
July 28th, 2009 in
Agile,
SCRUM | tags:
Agile,
Kanban,
SCRUM |
1 Comment
I recently sat in the pub with a couple of colleagues and the subject came up. It soon became apparent that, while we do things in very similar ways we do differ on the use of the word agile. We had views expressed from “stop using that word” to “it’s just good practice” and others I don’t recall.
So, it’s sad talking about this stuff in the pub but it has prompted me to dig a little deeper into my own perspective.
So, what does it mean? In a training course I run I refer to it as an umbrella term for a whole bunch of approaches many of which pre-date the use of the word (think SCRUM, XP, TDD, FDD …). In the same course I offer the definition
“To be able to deliver business value quickly and respond to change”
But still this doesn’t provide us with an ability to recognise “agile” when we see it.
At XP day in November I recall two conversations. The first was with a manager who proudly told me his team were running text book XP very effectively and had been doing for some time. I questioned him on the output of his last retrospective. I recall someone saying about XP; “If you’re still doing it by the book after a month then you’re not doing it”. I believe that while XP, SCRUM etc. are helpful we should be constantly looking for a better way. On the same day I spoke to a developer from much more traditional background who’s team were making small steps to improve the process. So which team was the agile one?
I see constant striving for a better way as a fundamental. Compare this with the Toyota attitude to perfection.
The word “better” is the crux of this. Where better for this team is in line with the agile manifesto they will evaluate practices according to the teams ability to collaborate, their ability to deliver value (i.e. the right balance of software, documentation and other artefacts), their ability to collaborate with the customer obtaining feedback and their ability to respond to change.
So, given this definition, the team is, for me, agile independent of their current state.
So what about all of the practices we see, don’t they contribute? My perspective on an effective agile team is that they should keep sight of how practices evolve and select new practices in line with their current constraint or pain.
Given my definition above, it makes no sense to state that I have an agile team. Rather I have a team that is delivering effectively and is constantly striving for improvements. Agility offers a continuum and the manifesto proposes the direction of travel.
February 24th, 2009 in
Agile | tags:
Agile |
No Comments
Agile approaches to software development can be seen as quite hostile to project management. I have been told in the past that “we no longer need PMs because we have a SCRUM Master”. This is not a line I agree with. Furthermore, I can see this type of attitude causing unnecessary hostility. In fact I see agile as offering tools to project managers that can make them more effective and better able to deliver to demanding customers.
So what does a project manager do?
For me, while a SCRUM Master is responsible for supporting the team and the Product Owner can be seen as a domain expert able to make calls on prioritisation the Project Manager should be focused on the project context. This is likely to involve commercial considerations, stake-holder management and external risk management as well as possibly choreographing deliverables from different suppliers e.g. software delivery and data centre space.
It is of little surprise that many in the development community feel the need to push back on PMs. As an industry there are many of us who have experienced over bearing, micro-managing PMs who seem to live to interrupt us mid flow and demand estimates as well as challenge actual time taken on a task. It seems that many PMs cannot appreciate the difference between an estimate and a quote as well as a seeming inability to acknowledge unachievable deadlines based on everything going right.
In fact, should we be so harsh? A PM is tasked with ensuring the success of a project. Many retain a list of risks with no opportunity to mitigate, hold a plan with no possible intervention point if things seem to be slipping and furthermore it is often almost impossible to measure our current project state against the plan.
It is my view that agile methods offer a set of levers to enable effective project management. Examples of these include:
- Effective tracking of progress through delivery of end to end features rather than intermediate documents
- Effective risk management and mitigation through early detection and adjustment of priorities bringing risky features forwards or perhaps deferring to a later release.
- Effective adjustment of the plan in order to increase / reduce scope or adjust release dates according to delivery track record. Again adjustment of priorities can play an important part here by working with the PO to ensure a cohesive stable product for release.
- Effective stake-holder management through constant feedback and re-evaluation of the business case.
So, in conclusion, while SCRUM was defined without a PM I see this as a crucial role in a commercial environment. While the PM will collaborate with the SCRUM Master and Product Owner (or equivalent in a none SCRUM team) this is a distinct role with distinct commercial and stake-holder management responsibilities.
February 23rd, 2009 in
SCRUM | tags:
Agile,
Management |
No Comments
