Tag Archives: scrum

The Tool Trap

As a life long fan of technology and one privelaged to work within a high tech industry, it’s easy to get distracted by the shiny…

Technology is nothing but tools. When you consider that the people who are usually most passionate about technology are the ones in the agile camp, the proliferation of agile tools in the market place has a sense of inevitability.

It is also the most common mistake we make as practioners, certainly when we start down this agile road. Agile = Cool so we want all the shiny cool new tools. Preferably one written in Ruby (or Python or Haskell). With many rounded corners and buzzword compliance.

I think the reason why we fall into this trap, why we find it so compelling is because we’re technologists. At our core, we believe that given the right tools we can change anything for the better. This unflagging optimism is why I read too much sci-fi. On my first real scrum job, I immediately went straight for the throat and tried to find the right tool to get this scrum stuff embedded into our development process ASAP. I believed that the tool would help us ‘do it right’. Turns out there is a word for this belief: Technicism

And I got it precisely wrong.

Agile adoption is a change process, and change is hard. We all too easily use technology to hide from change. My problem with most electronic scrum tools I’ve seen, is that it is all too easy to use them to hide the valuable stuff that help us to manage the change. (Maybe if we had the technology where all our walls were display screens that were also touch-sensitive it might be different.)

Change is also about humans. People. We’re complicated beasts and slow to change. So the best thing to use to bring that change about is the base instincts. For example, we’re social creatures. That means that the most important influences on our behaviour can be found in our peers. This is a function of our evolutionary history. So use the peer pressure to help drive behaviour. A visible example of this is the daily stand up.

In a recent conversation with a much wiser man than myself, Peter offered the not entirely surprising insight that most agile teams which move from a physical (cards, sticky notes, scrum boards) to an electronic one, usually go back to the physical. I believe that there is a sinister conspiracy at work: Scrum is in fact a 3M marketing ploy. The insight that I get from this is one that is easily lost in a cubicle farm. Making software is a social activity, and the technology we use to communicate is a poor analogue for our evolved communication patterns. Alistair Cockburn has a graph which illustrates this wonderously. In fact go read his talk while you’re at it.

So what I have learned is that this agile stuff, works a whole lot better when I step away from my identity as a tool user / maker. In fact I get a warm fuzzy feeling whenever I see my team in front of our scrum board…

Advertisements

Hero-Driven Development

I feel like I may need to start this post by paraphrasing a song: “You’re so vain, you probably think this post is about you.”¬† I have had the privilege of working with some remarkable technologists during my career and the danger is that they misinterpret what I’m about to write about. Steve McConnell calls them “10X Developers“. They’re the ones who can produce code at a rate of 10 times that of the average. Every software company would like to employ them, and some believe they do.

What I’ve started to notice is what amounts to an organisational anti-pattern.

Anti-Pattern: Hero-Driven Development

http://www.flickr.com/photos/roby72/3345955051/

Captain Squarejaw to the rescue

Problem: Whenever some gnarly problem raises its head, the Hero is sent to fix it. The team sit back and let the Hero work, maybe watch what The Hero is doing. The Hero fixes the problem (slays the dragon) and the team gets back to doing what ever it was they were doing till the problem was discovered. The Hero flies off into the sunset.

Context: The team has hit an impediment which is within their theoretical skill base but without the experience or resources to fix the problem. The person accountable for delivery is panicking. The team is thrashing and seem to be getting no closer to a solution. Someone lights the signal for The Hero who swoops in to save the day.

Forces: Every software development project is a hostage to budget and schedule. In this context it makes sense to solve the problem as quickly as possible. But this is inevitably a short term fix; depriving the team of the opportunity to learn from failure and pain means that their growth will be stunted. The team’s ownership of their work diminished. In the worst case scenario it can lead to a loss of confidence and morale. There is also the danger that over time, the threshold of what is considered a problem will decline. The perception could evolve that the Hero gets all the interesting work. And worst of all, that any work done by The Hero is immune from scrutiny.

Solution: Trust the team. This is their problem, their mess. Support them where needed, get them expert help, but make sure that the team does not lose ownership of the solution. The Hero can still step in to help the team solve the problem, but the difference is in how the help is evaluated and used by the team. This is an act of collaboration and not an act of salvation. It is vital that the Hero be seen mainly as a ‘consultant’ to the team, whose output should be mainly advice. If The Hero is writing code, it needs to be dealt with in the same way as any other developer’s code. It should meet the team’s “Definition of Done”. And ideally, it should be reviewed publically so that the team can learn from the event and hopefully improve (Inspect and Adapt). It is better as a longer term strategy to have a team of heroes than to depend on a single person to solve all your problems.

Note, I am not concerned in this post with primadonnas or those who don’t share their knowledge. This is not the true Hero. If I had my druthers, I would fire those people from any organisation I was working for. In my experience someone who is trying to make themselves indispensable in an organisation deserves to be shown the door; they are acting for their benefit and not of their team mates or company.

Orlando Gathering

For those of us not lucky enough to be in Orlando right now, the Open Space findings are being captured at:

http://scrumorlando09.pbwiki.com/browse/#view=ViewFolder&param=Orlando

Presentations are also being published to the Scrum Alliance site at:

http://www.scrumalliance.org/resources?tag=SG+Spring+2009

Scrumbaiting

There has been some vigorous discourse about the state of scrum in the past few months. I’m not going to refer to them specifically.

What it feels like is that scrum has reached a level of acceptance and recognition that it has now become mainstream enough to warrant the kinds of attacks that can build your reputation. Everyone loves the little guy; this is why it is useful to frame arguments as a battle between the little guy and the big guy. The insight to take away from this is that rising to the bait will only encourage more baiting. There is no right way to do this.

At the moment I feel a bit like scrum’s bulldog.

I think Martin Fowler probably has the right insight. The baiting, criticisms and misunderstandings will be an inevitable aspect of the growth of scrum. what we as a community need to do is emphasise the technical aspects of a scrum implementation that will ensure success.

Nothing succeeds like success; which means that in order to be successful, we need to do more with regard to practices like continuous integration, automated regression testing and test driven development and refactoring (especially in the architecture area).

The one area where I will usually reply to percieved criticisms is where I think it is founded on a misunderstanding of a practise or role.

The Nokia Test (reloaded)

I’ve published a little TEST for those of you brave enough to find out what level of scrum you’ve implemented. It is based on Jeff Sutherland’s presentation on ‘Money for Nothing, Change for free’. In it he describes an updated version of the Nokia Test.

I’ve taken the liberty of turning it into a very basic quiz running on googledocs. (Please let me know if you experience any issues with taking the test, I’ve tested it but you never know)

I suspect that even this test is still too basic, it does give you a somewhat better feel of whether you’re doing scrumbutt or better. I found it useful as a focus for a review session. It draws attention to the basic practices that you should have in place. And until those basics are in place, you don’t really begin to feel the full benefits of what scrum has to offer. Jeff puts up some empirical evidence in his presentation that suggests that an excellent scrum implementation can make a difference of 400% in your productivity as a team (however that is measured).

You owe it to yourself and your team to make sure those things are there, and if they’re not figuring out a way to get them there.

Design is a team responsibility

This leads on from a comment on my previous post. The implication seems to be that in a new project, scrum will tend to result in a ‘design by committee’ design-smell or anti-pattern.

From Wikipedia: “The defining characteristics of “design by committee” are needless complexity, internal inconsistency, logical flaws, banality, and the lack of a unifying vision.”

The implication is that the ‘right’ approach to design is to find some genius designer to produce the perfect design from your requirements and communicate it to the team to implement. This ideal is in many ways similar to the genius fallacy we find in fields like science and the arts. In this media-driven ideal, the genius isolates himself from society and the outside world until he returns with the perfect idea written on a stone tablet, like a revealed truth. The reality is that even reclusive genii like Newton and Einstein worked collaboratively and benefited from the interaction with their peers.

Furthermore, the prevailing metaphor for software developments’ design process (architecture) is a poor description of the actual development process. In a construction project, an architect designs the building right down to the specification of the materials to be used. The people who build the structure have no latitude in the choices of how to implement that plan, and certainly are not expected to exercise their creativity in the execution of their tasks.

This is in stark contrast to the expectation we have of software developers. These are smart creative people who we ask to do what amounts to one of the most difficult endeavors humans have ever attempted. Trying to restrict their ability to apply themselves to the problem by constraining them to a design which they did not participate in, is a poor use of these human assets.

The design is only going to be as good as its implementation. By involving the whole team in the design process, buy-in is created which will translate into a better implementation of the design as a whole. In my experience, a ‘stone tablet’ design is viewed as an obstacle to be overcome rather than a solution to a complex set of inter-related problems. It means that when a developer is faced with a choice of expedience vs. following the design they would be more inclined to follow the design, because it is their design. Or to raise issues with the design during implementation to allow for its improvement.

The other important design lesson from agile development is that design evolves. The Construx white paper on scrum (note: registration required) rightly (in my view) points out that scrum does demand a degree of experience in being able to design an architecture that will gracefully evolve over the lifetime of the development. This is hard work.

Ken Schwaber (in the video of his presentation to Google, ‘Scrum et al‘ talks to this point as well. A scrum team will need to design an architecture and then implement some feature which will use this framework in a tangible way. Driven by the time-box this means that the framework by necessity¬† will have to be small enough to fit into sprint, and will add features incrementally. But it also means that you’ll find out early whether or not your chosen architecture will deliver on its promises.

Further your design within the sprint is contrained to Sprint Planning 2. Typically this means that you’ll need to formulate and communicate the design to the team in a max 4 hour meeting. I suspect that some would argue that ‘Sprint Zero’ would allow for some design as an activity with artifacts produced that are not code or working software. My gut feel is that ‘Sprint Zero’ is an aberration. You may find that within the context of an enterprise environment, where architecture documents are a governance requirement there would be a tendency to push for this.

I would contend that the right place to produce those documents is within a ‘normal’ sprint where the goal is still to produce some working software. After all, the point of scrum is to do just that. Any architecture produced in ‘Sprint Zero’ should be a broad brush stroke rather than a detailed final product.

Similarly, the design produced in ‘Sprint Planning 2’ should be the stuff of flip charts and white board photographs. Producing the UML diagrams and other design documentation should be done in the sprint. It’s a task, and anyone in the team should be able to pick this up. This is design as a collaboration; a group activity.

The role of the architect then is as an expert with experience in design and someone who actively shares that knowledge and experience with the team. And with the flat team structure in a scrum, it means they’re much more likely to also code, which I think is required of a good architect. Think of it as forcing him to eat his own dog food.

Lastly, design by committee as an anti-pattern is described on this website as something that usually happens when the size of the group exceeds 6-10 people, which is also handily about the size your scrum team should be. I think much of the negative press that architecture and design receives is the way that it is implemented in a waterfall-style organsiation. It’s a valuable, important part of the development process, and it has an important role to play in an agile process. It just does not (and should not) receive the level of ‘celebrity status’ it currently has.

Cape Town Scrum User group – 6 Nov

I attended the second scrum user group meeting in Cape Town last night. A bit smaller than the launch, but still well attended. The format was a panel discussion with Peter from Scrumsense, Boris Gloger (in town for training) and Steve from MagmaTech.

Using a scrum task board for tracking the questions, it started with the usual question about what “It” is. (I have this urge to riff on the Matrix; “Unfortunately, no one can be told what scrum is, you have to see it for yourself”). Boris used the phrase that is the name of this blog: “Scrum is Scrum”. Who knew germans could be so inscrutable?

A poor fellow soul from Old Mutual asked for advice on how to implement scrum in a restrictive environment like OM. Boris’ answer was terse: “Just do it”. I saw a bit of myself in there; as technologists we want tools and guidelines.

The truth is that all you need to do scrum is: Know what it is and have a desire to do it. And maybe some stationery. Be brave, just do it.

We very quickly got into more meaty topics. The first one which I think was of interest was around Architecture. The question ventured that ‘design by committee’ was not a good idea and how scrum responded to that. The insight was really that, an architecture designed in isolation by an ivory tower architect did not accord with scrum principles. A cross functional team has value to be added in everyone participating in the activity.

This quickly degenerated however into architect slagging (e.g. they can’t be trusted, keep them away from your project etc.).

Another question was about analysis for the next sprint. Boris ventured that spending perhaps 10% on prepping for the next sprint was a good use of time, but that it should not necessarily be the sole province of the analysts. What was important was for the analyst to be prepared for Sprint Planning One; this is the analysis phase of the sprint, and any questions the team has, the analyst needs to be ready to answer. But this analysis should be communicated in the planning session with flip chart diagrams etc. Where analysis documents and artifacts are required to be produced by the team, this should be a task for that story to be done in the sprint.

Which led back to the previous point about design & architecture. If Sprint Planning One is about Analysis, then Sprint Planning Two is about design. Most teams use this meeting to create the tasks for the stories. SP2 should be workshop where the team design the solution that will be implemented for a story. Make some notes to capture that, but don’t laboriously create all the tasks required.

Another question examined the intention of the Sprint Review (or demo). There was some confusion I think since some people also use the term “Sprint Review” to refer to the retrospective. Boris highlighted that the intention of the “Sprint Demo” is to critically examine the functionality produced and how it has improved the product being produced. Too often this session has a tendency to be a chance to reward or to punish the team for performance. Either of these actions detracts from the teams self-management. The “Sprint Demo” should be focussed on the product, and should find the areas for improvement.

A question was around the ‘anarchy’ inherent in letting a team manage itself. This I think is a pernicious misreading of what the role of management in the team context is. The team is still subject to standards (of the organisation) and guided by the priorities established by the Product Owner. As someone from the audience pointed out; the longest a team, or team member should be allowed to ‘go rogue’ would be one day. When the next daily Stand Up rolled around, they should be reigned in by their team members or scrum master.

A clarification of what constituted an Impediment was requested. This boiled down to “anything that the team cannot accomplish” is by definition an impediment; else it is just a task that needs to be completed.

Our timebox finished around then, and it broke into smaller groups of private discussion.

Mention must be made of the uber-cool 24.Com room we met in. With its large screen TV, XBox360 and dual guitars for Guitar Hero, this was an office I would not mind working in… Add some draft beer taps into there and a really good coffee machine, and I doubt their employees would ever leave the building. Wait a second, I think I’m onto their feindish plot…