A few weeks ago at the local Ruby Users Group meeting there was a suggestion of actually writing some code at the meeting. The suggestion was to use a Ruby Quiz exercise. It was quiz #16, a Rock, Paper, Scissors simulation. We broke up into small groups of about three people, coded for maybe 45 minutes and turned in our solutions. My team came in last but it finally pushed me to actually take up a long neglected todo item to start doing coding katas on a regular basis.

I’ve done the classic Bob Martin TDD bowling kata for years as an intro to TDD. I’d also walked through a one day tutorial from a Dave Astels session on Rspec back in 2006 that was very much a game based kata. I’d read about Prag Dave’s coding kata ideas, but I’d never quite found the time to start the practice.

Last week I started utilizing two major resources:

• Prag Dave’s original CodeKata site.
• The KatCatalog from the Coding Dojo wiki.

I’m jumping back and forth between Java and Ruby in the katas to stretch my skills. I may even add in Groovy at some point, but Groovy and Ruby styles are pretty similar. I’m trying to take on one per day and when I wrap around I’ll try out different languages. As a committed TDD student I’ve started each kata with a test. I have to admit RSpec makes this a lot easier when using Ruby and autotest is a wonderful tool. At least I have annotations and JUnit 4+ when I’m doing the katas in Java. For IDE’s I’m bouncing between IntelliJ for Java and TextMate for Ruby. I’m even taking the opportunity to test out git and I setup a github account to store the katas so I can see how I evolve over time.

If you haven’t tried out the practice I might suggest giving it a go. One of the best things is I get to really focus on coding for about an hour a day and it blocks out the rest of the world. Mostly I’m doing them in the early morning to cut down on the interruptions. I’ll probably post again on my observations after a month or so.

Agile software development teams often use User Stories as a simple and concise way to express user requirements.

Ideally these User Stories are broken down as small as possible, whilst also trying to minimise dependencies.

Naturally, though, as you break User Stories down smaller, they become increasingly inter-dependent. Like most things in software development, it's a balancing act.

Break the User Stories down as small as possible. But stop breaking them down when it becomes onerous or pointless to do so. When a User Story can be delivered (done) in less than 1 day, I think there is little point breaking it down any further.

Use the concept of Themes to categorise these related User Stories under one label and keep them together.

You could physically keep the cards together by paper-clipping the cards together. Or you could put a card representing the Theme on the left side of your whiteboard, and keep all related User Stories on the same row as the Theme as they move across the board.

Equally important, try to make sure that any inter-dependency between User Stories is a soft dependency, rather than hard. By this, I mean that you might not want to ship any of the User Stories until the whole Theme is done. But try not to break them up in such a way that one User Story simply doesn't work without another.

For instance, a 'Login' Theme might include User Stories for Register, Log in, and Forgotten password. Although the stories are related, and somewhat dependent on each other, they can still be delivered in isolation, and can still work from a user perspective if you do them in the right order.

You can also use Themes to categorise loosely-related items on your Product Backlog. For example, on a web site, you might have a whole host of User Stories relating to SEO, performance, usability, a re-style, or sections that are made up of multiple User Stories.

Assigning Themes to the User Stories in your Product Backlog can help you to see emerging themes, which with a loose set of User Stories you may not have noticed. When you see emerging themes for your next Sprint or two, this can help to give extra clarity to the team and business about the Sprint Goals.

This is a useful thing to do. It gives you more of a message for the Sprint. It's actually *about* something, rather than a random collection of high value but unrelated stories. It could tell you that you're focusing a high percentage of your Sprint on features x and y, when at a macro level your priorities are really elsewhere, for example.

It also helps when priorities are set top-down. For example, let's say we make the commercial decision that for the next few sprints SEO will be a top priority. You can quickly grab all the User Stories with the SEO Theme and give them priority.

Of course it's fine for a sprint to include items that are not part of the overall Theme. The theme is simply the main area of focus, not necessarily the sole area of focus.

There is sometimes a danger with agile software development that everything is broken down so small and incremental that everything becomes a bit too tactical, and there is either no direction or at least the direction is not apparent.

It's important to keep a higher level Release Plan, or a Product Roadmap, so the Sprints do take the product in a certain direction, and so the team can see what that direction is. Because no Sprint is an island!

You can also use Themes as a simple way to sketch out broad priorities on the Product Roadmap, showing the key areas of focus over time.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by *phototristan

Agile software development teams often use low-tech, manual methods for tracking their work. Post-it notes or cards on a whiteboard. Charts drawn by hand. Sketches for architecture and design.

But why, for such a high-tech industry like software development, would agile teams do this, when there are plenty of project management tools available; even tools that are purpose-built for agile software development?

Personally I can see why. I think a whiteboard offers loads of advantages over electronic tools. They're mainly soft factors, I admit, but I think a whiteboard is hard to beat.

First of all, a whiteboard is visual. And it's BIG. You can see at a glance how things are going.

When you're part way through a Sprint, and most of the cards are still on the left of the board, you know it's not going so well. Or you're coming towards the end of a sprint, and the cards are mostly - reassuringly - on the right of the board, you know it's going fine. The Burndown Chart shows you instantly whether the team is on track. And, if not, by how much. All at a glance as you walk past the board. Whether you made a special effort to look or not. The visibility is unbeatable.

When you see something in print, somehow it seems more real. I guess because it's physical. A large number of post-it notes on a whiteboard looks like a lot of work. Probably because it *is* a lot of work! Its sheer physical presence reflects the amount of work the team is actually doing. It feels busy. It feels like a place where alot is happening, which feels good. A long list of tasks on a project plan, or a long list of rows in a spreadsheet, simple doesn't have the same impact.

A whiteboard is also flexible. Infinitely flexible. You can put literally anything you like on it. Wherever you like. In any position, any size, any shape. Unlike an electronic system, there are never any constraints. No-one ever says you can't do something because the whiteboard won't let you.

It's fast and efficient to change. You could completely reoarganise a set of cards in just a few moments. Or sketch something important in seconds.

It's also more tactile. For people that like tactile, it feels good to move a card to done. You feel a sense of ownership when you pick up a card. A business owner feels a greater sense of responsibility - real acknowledgement - when they add something to the board and take something else off the board to take it out of scope. It feels like something was actually, physically removed from scope.

It's also novel. When a team starts doing agile - and they create great visibility using the whiteboard - it's remarkable how many people want to come and look. Senior people have a sudden interest in what the team is doing. And even in the process itself. That would never happen with spreadsheets and tools! I can't ever remember a Director asking to come and walk through my project plan, or walk through my product backlog. In fact the very thought of it fills most people with dread! It just doesn't happen. But the whiteboard is interesting. It's interesting to look at. And interesting to talk about. When someone walks you through it, it's actually enjoyable.

Because a whiteboard has no set structure, it suits the way many people think (not all). Many people think visually. Not in lists, but in shapes, sizes, colours, etc. The whiteboard's lack of structure allows the information to be organised and presented however suits.

Important information can be highlighted easily by putting it on the whiteboard. Important information is not buried with loads of other documents and files in a project folder somewhere, which few people would browse and certainly wouldn't notice in passing.

Its visible nature can prompt people to remember things when they see them, rather than relying on their memory to go and look somewhere else that's out of sight.

But above all else, the whiteboard is a place for collaboration. It's a focal point. Like a campfire in days gone by. Or a fireplace in your lounge. Most team discussions happen round the whiteboard. Discussions about progress. Discussions about issues. Discussions about design. All sorts, sometimes even when the whiteboard isn't even needed. It becomes the hub of information for the team. The hub for communication and collaboration.

And last but not least, the unstructured nature of the whiteboard allows it to be be personalised by the team. The team can express itself through the things it puts on its whiteboard. It starts to show the character of the team, and therefore helps to create a visible sense of team spirit.

Tools can certainly help to organise information more efficiently. But I would challenge any tool to do all of that! I'm not against tools. Not at all. But I think they should supplement the whiteboard, not replace it. Tools should be used for things they can do that a whiteboard can't. For instance, keeping track of longer lasting information, doing calculations, searching, etc. But personally I don't think I'd ever use tools instead of a whiteboard. There's simply too much to lose.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by Fernando Meyer

I've spent the last 2 years or so reaching out via my blog and posting all sorts of comments and information about my experiences with agile software development. I am now thinking of running a seminar, in order to do the same thing on a face-to-face basis.

I think the area where I have most to offer is for people starting out with agile; people that might be interested in my explanation of the 10 key principles of agile, and my explanation and experience of how to implement Scrum.

I have seen significant benefits from implementing agile development using Scrum, having implemented it successfully in many teams now. I'm really keen - as I have done so far with my blog - to share my experiences with the community. Hopefully on a face-to-face basis I should be able to really bring some of this experience alive, and share some important information about what has worked for me in practice.

I haven't set a specific date yet. Or a definite price. My idea is to do this as a half-day session, in London and at a decent venue.

This is where I need your feedback. The purpose of this blog post is simply to sound out my blog readers and find out if there is sufficient interest to run the event? If you would be interested in attending, or have any feedback for me, I would love to hear from you. You can email me at allaboutagile@gmail.com.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

Agile software development has been a revelation for me. It has brought me and my teams much success, and a very rewarding working environment.

Sometimes I hear people say that agile development isn't appropriate in all circumstances.

In fact, I used to say that myself; however now I'm not so sure.

There are some circumstances where an organisation's culture is possibly too different to successfully adopt agile. At the moment I can think of only 3 reasons why I wouldn't do agile software development:

1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.

2. If I was working for an organisation where the relevant product owners couldn't - or wouldn't - commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.

3. If I was working with a team that I didn't believe could cope with ambiguity, or didn't have sufficient communication skills to collaborate effectively with business colleagues or customers.

In these circumstances (particularly if combined), adopting agile could be very difficult indeed, because in my experience these 3 agile principles are critical success factors!

When writing this list, I did also wonder whether to add fixed price projects to my list? Working from a feature list, having no more detail about the features up-front, and allowing change throughout the project, could potentially be a complete disaster with some clients on a fixed price contract.

I think I would do agile on a fixed price, but I would be very careful to:

• Understand the client's attitude towards scope up-front, and be very clear about the fact it's fixed price, not fixed price and fixed scope. In other words, they can add or change features throughout development, giving them the benefits of flexibility, but will need to remove other features to do so.
  
  
• Build in sufficient contingency and allow for a reasonable number of changes to happen without too much debate. You are taking the risk on a fixed price project. The client needs to pay a premium to offload that risk to you.

I would evaluate the above two issues - along with any other risks - very carefully before committing to a fixed price agile development project. Otherwise, whether accidentally or deliberately, you could quite easily get mugged :-(

On the other hand, I'd probably try to persuade the customer that T&M (Time & Materials) is not a problem with agile software development, because of the level of collaboration, visibility and transparency, and the frequent delivery of working software.

I'd love to know your thoughts on this: When wouldn't you do agile software development?

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by dominicmercier

I've written quite a bit about various aspects of estimating in agile software development. I think it's about time I joined up the dots...

PRODUCT BACKLOG

The Product Backlog is a feature list. Or a list of User Stories if that's your approach. Either way, it is a simple list of things that are of value to a user - not technical tasks - and they are written in business language, so they can be prioritised by the Product Owner. There are no details about each feature until it is ready to be developed, just a basic description and maybe a few notes if applicable.

'POINTS MAKE SIZES'

Each item on the Product Backlog is given a points value to represent its size. Size is an intuitive mixture of effort and complexity. It's meant to represent 'how big it is'.

FIBONACCI

I like to use the Fibonacci number sequence for the points values. Fibonacci goes 1, 2, 3, 5, 8, 13 - where each number is the sum of the previous two. This builds a natural distribution curve into the estimates. The bigger something's size, the less precise the estimate can be, which is reflected in the widening range between the numbers as they get bigger.

RELATIVE ESTIMATING

Points are an abstract number. They do not convert to a unit of time. They are simply a *relative* indication of size. In other words, a 2 is about twice the size of a 1. A 5 is bigger than a 3, but smaller than an 8. Developers find it hard to estimate accurately in hours or days when they don't yet know the details of the requirements and what the solution involves. But it's easier to compare the size of two features relative to each other.

ESTIMATE AS A TEAM

The points should be assigned to each backog item as a team. The collective intelligence - or wisdom of crowds - is an important way to apply multiple people's experience to the estimate. If you have a very big team, you can split up so it's quicker to do this, but the estimating groups should ideally involve at least 3 people, so you dont just get two opposing opinions.

PLANNING POKER

Planning Poker is a fun technique to facilitate rapid estimating as a team. The team discusses a feature verbally to understand more about what it entails and how it might be done. Each team member writes what they think its size is (in points) on a card. All team members reveal their card at the same time. Differences in opinion are used to provoke further discussion. Maybe one person saw risks and complexity that others didn't. Maybe another persion saw a simpler solution. The team re-votes until there is a concensus, then moves on to the next item.

DONE MEANS DONE

During the Sprint, or iteration, the team only counts something as Done when it is completely done, i.e. tested and signed off by the Product Owner. At that time, and only at that time, the team scores the points for the item.

BURNDOWN

The team shows its commitment and daily progress on a graph, so it is measurable and visible at a glance. This is called a Burndown Chart. The burndown shows the total number of points committed to, depreciating over time to the end of the Sprint. This is the target line. It also shows the actual number of points scored each day - i.e. the sum of points for all items that are 100% done and signed off so far. The team plots this each day before their daily stand-up meeting. When the actual line is above the target line, the team is behind. When it's below, they're ahead.

VELOCITY

At the end of the Sprint, the team's score is called their Velocity. The team tracks its Velocity over time. This allows the team to see if it's improving. Of course at some point it will stabilise, if the team is stable. If not, this is an issue in itself. When Velocity is relatively stable - in my experience that will be after 3 or 4 Sprints - it can be reliably used to decide how much (i.e. how many points) the team should commit to in the next Sprint.

RELIABILITY / PREDICTABILITY

As a result, the team can measure how reliable - or how predictable - they are. The metric for this is Velocity (points scored) as a percentage of points planned. As Velocity stabilises, the team's Reliability will get better, and the team will be better at predicting what they can deliver. Ironically, the team doesn't need to get better at estimating to get better at delivering on their commitments. Even if they are terrible at estimating, as long as they are consistently terrible, with this method they will still get better at predicting what they can deliver.

POINTS VERSUS TIME

One of the benefits of points is that it does not relate to time. Resist the temptation to convert it. If a team plans on 100 points and delivers 50, can you imagine telling your stakeholders that you are only planning future Sprints for half the team's time. If a team commits to 100 points and delivers 150, imagine telling the team you're planning on doing 60 hours each per week. It just doesn't work. Points are not a measure of time. They are abstract, relative sizes, and a measure of how much can be delivered. That's why it works. It works because the team can adjust its commitment based on what its track record shows it can usually deliver.

PRODUCTIVITY

This does not measure a team's productivity. Velocity does tell you if a team is getting more or less productive. But you can't really use Velocity to compare the productivity of two teams, as their circumstances are different. And you can't use it to determine whether a team's Velocity is as high as it should be. For this, you still need to use your judgement, based on previous experience and taking into account many subjective factors.

PLAYING THE SYSTEM

Using these two metrics - Velocity and Reliability - it's hard to cheat the system. If a team commits low, they acheive Reliability but Velocity goes down. If a team commits too high, their Velocity goes up but their Reliability goes down. This is like the balanced scorecard concept. The metrics are deliberately measuring opposing things, so they can't easily be played.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by Steve Kay

Here's an interesting article about agile software development and lean development, written by a senior analyst at Forrester Research...

"Agile Processes Go Lean"

It's nice to see agile and lean getting such positive recognition from an organisation as credible as Forrester.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by Antoine

Bruno Sbille and his team have made this video as a nice light-hearted way to show how they used Scrum agile software development on a real-world project...

Scrum methodology from Soul' on Vimeo.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

Most of my experience of agile software development has been with Scrum, and some aspects of eXtreme Programming (XP). However, for quite a while now, I've been reading quite a bit about Lean software development, and Kanban.

For those that don't really know much about Kanban, I found the following article on InfoQ quite an interesting insight:

http://www.infoq.com/articles/hiranabe-lean-agile-kanban

I haven't made the jump and tried Lean with any of my teams yet. To be honest, I've had such great success with Scrum, across so many teams now, it's almost a case of "if it's not broken, don't try to fix it".

Having said that, I do see that the overhead of Sprint planning in Scrum is often quite onerous. Although I really value the predictability teams can achieve by estimating in points and tracking Velocity and Burndown. I've seen this help so many teams to deliver on their commitments, meeting expectations and building strong business relationships as a result.

But I can't help being slightly fascinated by the idea of cycle time in Lean software development. This is the idea that a team's cycle time represents the average number of cards - or User Stories - a team can deliver in a fixed period of time (iteration). To work best, user stories would ideally be broken down until they are all a similar size. Although not necessarily, as what's important with cycle time is the average number of user stories that can be delivered in a Sprint. When you think about it statistically, the concept is actually very similar to Velocity.

What if a team could achieve the same level of reliability and predictability, without the need for any detailed estimating and planning? There would certainly be an increase in the team's productivity, due to the time saved on Sprint Planning.

My sense is that doing Lean - and using cycle time to predict when things can be delivered - may well be appropriate for business as usual. Ongoing development is, by nature, more routine. And therefore the team is more likely to get into a more predictable rhythm. But for bigger projects, where costs need to be estimated in order to secure funding, and the project team is not yet established, I'm not sure if cycle time would be predictable enough?

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

Lean software development shares many of the key principles of agile software development.

Although one of the key aspects of lean development is all about identifying and eliminating waste from the development process...

One of the most hotly debated aspects of this is estimating. It clearly doesn't contribute to the end product itself, but is estimating really waste? Or does it really add value to the process?

This post on the LitheSpeed blog, 'To Estimate or Not To Estimate, That is the Question', asks exactly that.

The answer? I guess it really is a matter of opinion. My personal answer - Like most things in life, I think it depends!

I think I agree with Sanjiv. If you're working on high priority bugs, in severity order, and they must be fixed, estimating how long they will take provides little value, except to help manage expectations about when the bugs might be gone, which may or may not be useful depending on your circumstances.

On the other hand, if you need to create a business case in order to secure funding for a special project, or you need to commit to a deadline to fit in with other dependencies like a launch date, estimating is clearly necessary, whether it adds value to the end product or not.

I think actually that's really the wrong question though. Clearly there are many scenarios in business where you do need to estimate when something might be done. But you may not need to estimate the size of each feature or the effort of each task in order to predict a delivery date.

With a large enough sample size, keeping track of the average time per feature, or cycle time, could potentially be a reliable way of predicting how long something might take, without actually estimating it.

My concern about this approach is that, statistically, all items must be as near as possible to average to achieve any level of predictability on a single piece of work. I'm sure on a large project, everything averages out. By definition it must do!

But on smaller pieces of work, where you're working to short timescales, any feature that is higher than average gets delivered later than expected. And that can cause problems.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by bushn

It is sometimes said that agile software development methods, such as Scrum, are ideal for small projects being delivered by small teams.

Personally I would certainly agree that Scrum is ideal for small, multi-disciplined, co-located teams, working on a common purpose.

However, these days we hear plenty of examples of larger companies using Scrum on a fairly large scale. I seem to recall Yahoo in particular once stated they were using Scrum on a project with 700 developers!

Of course it is relatively straightforward to scale Scrum up when the teams are basically a collection of small unrelated teams, each using Scrum but working on different projects. But what about when you need a very large team working on a single project, or on closely related projects in a large programme?

One technique for handling this - although I'm sure it's not enough on it's own by the way - is a technique called 'Scrum of Scrums'.

The concept is simple. Each team meets every day and holds their daily Scrum as usual. One or two representatives from each Scrum team attend a higher level Scrum to coordinate across teams. And on very large teams, one or two representatives from the higher level Scrum attends an even higher level Scrum, and so on.

It means some people need to attend two Scrums, but the Scrum of Scrums technique scales up very well and is easy to see how important information can be quickly cascaded all the way up the line on very large projects.

But the information that needs to be communicated, and the frequency of communication, shifts as you go up the line, and the process for a Scrum of Scrums needs to be slightly different from a usual Scrum.

Mike Cohn - popular author of Agile Estimating and Planning and User Stories Applied - has written a blog post giving his advice on how to apply the Scrum of Scrums technique...

Advice on conducting a Scrum of Scrums - by Mike Cohn

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...

A Backlog Item is a defined as "Deliverables, Stories, Functionality Requirements". A Backlog Item can be anything as long as the team understands that it has to have business value and is meaningful for the Product Owner.

Introduction Most folks don't like change. I know I don't. But one things certain, adopting an Agile approach to software development requires much change in an organization. Whether it's corporate culture, roles or process, as an organization switching to Agile you're going to have to learn cope with change. This series deals with how various functions in the Agile organization are expected to change in order that teams new to Agile can learn what to expect and better adapt to this new and invigorating environment. This week covers the changes one can expect for the Customer and Product Management function... Jack Milunsky

I have been espousing an understanding of principles for quite some time now. While I do believe that one typically does not truly understand something until they do it, I believe we often look in the wrong area for things and that being told what to look at (in the form of principles or rationale) can steer us into better action quickly.  I recently had an experience of not being told principles, eventually learning things myself, and realized I would have learned a lot faster had I been told them - so I thought this might be a good illustration of my point.

I am reasonably physically capable, middle-aged guy. When I was in my 20s and 30s, I was fairly athletic, playing football and basketball quite a lot (and was pretty good at them). I've also enjoyed boating and have been doing that more recently. I've been on a recent activity kick and started kayaking. Up until a week or so ago, I'd probably only kayaked 2 or 3 times in my life (canoeing and sailing had been more of what I did). In other words, I'm somewhat athletic, but not in as good shape as I used to be and not an expert at Kayaks but understand the basics of boating.

Anyway, last Friday I went out with my 19 year old son Bryan and we tandem kayaked (that's 2 people in one kayak) for an hour on Green Lake near my home.  Green lake is a relatively small lake where it's real easy to get around.  Smooth water, very little wind.  My son was in the front, I was in the back. Now I'd seen tandem kayakers go at it and noticed how they always stroked on the same side as each other, alternating left and right.  I figured this was so their paddles wouldn't hit each other.  We sometimes did this, sometimes didn't.  I could keep form hitting my son's paddle and we weren't in any hurry so we never really went very hard.

Then, a couple of days later, I tandem kayaked with my daughter (in her 20s).  But this time we were on Orcas Island (still there).  This was the first time my daughter had tandemed too, although she had some experience as a solo kayaker.  We had a great time and again I was in the back.  Sometimes we'd stroke together sometimes not. Again, we weren't pushing anything and the wate was very calm again.

Then yesterday, I went out with my duaghter again, only this time, she sat in the back - figured it was nice to try something different.  The weather was a bit windy that day and therer was a strong current in a few places.  While we weren't in any hurry, the current made paddling take more effort.   Most of the time my daughter would paddle, but at times, she'd get tired I'd paddle by myself.  When she did paddle, we werern't usually in synch - Lisa would usually just paddle, as I had done the day before, without paying any attention to the person's in the front timing. After about 45 minutes (we knew we were going out for only an hour), something interesting happened.  We had been putting more energy than we had earlier into our paddling to cross the bay.  It was windy and a bit cold and it seemed fun to have a strong effort. I was digging a little harder and could feel how I was pulling the boat across the water with my paddle.  This took a fair amount of energy.  But about this time Lisa started paddling in tandem with me - actually, somewhat by accident.  The experience changed dramatically.  The boat all of a sudden took what seemed like only half the energy to move forward faster than before. 

The last 15 minutes we paddled like this and it was so cool.  What felt like half the enegy was getting us more speed.  I realized that my thinking before was that Lisa and I were just independent motors.  We werer putting out energy with our arms, moving the kayak through the water.  The way we worked together wouldn't make any difference.  Physics tells you that for every action there is an opposite and equal reaction - so the timing shouldn't matter.  But then what happened? On reflection I realized that by paddling together, we could reach the same speed as before  with less energy because we were pulling on the boat together. It was like lifting half of a heavy bag with someone - it takes less energy.  Lowering the energy level of each stroke because we were pulling the boat togethe, meant we got less tired.

To be honest, I am not exactly sure of the physics. I am guessing we coasted better between strokes (now both of us together each second) than when we were - between us - touching the water 2 times a second.  The point is, I had been using the wrong rationale for paddling.  Had I been told we would be more efficient in the use of our energy by tandem paddling, we would have learned how to do it much earlier.

So what's my point?  Had someone talked to me about tandem kayaking and said something like: "While you may not understand the physics of it, but stroking together on the same side will work better than stroking individually. You'll get more speed for the same energy - or the same speed for less energy."  In other words, while you may not get an actual experience of things until you do it - and therefore you real understanding will be lacking - you can accelerate your experience by being told the principles or rules of what is going on.

And why is this on a software blog?  Because understanding Lean principles can be very helpful in people trying to learn / create new practices for themselves and their teams.  Having to figure out from the experience alone is not as good as understanding why things work the way they do.  Then, when you experience it , you truly know it.  Lean has (at least) two major areas of looking at something different than many people do: 1 - look to the system for errors, 2 - pay attention to time, not how productive (busy) people are.

Alan Shallwoway
CEO, Net Objectives
Achieving Enterprise and Team Agility

 

 

Okay... you're a few months into your agile roll-out. You did all the right stuff before you got started. Got sign-off from the execs... check... got team members trained... check... identified a pilot project... check... hired an agile coach... check. Why then... after all this time, effort, and money... are we still struggling with the fundamentals? Why can't we seem to get over the hump?

It seems that there is always someone... sometimes there are a lot of someones... that just don't seem to get it. They just can't let go of their trusted MRD... they can't seem to get past the idea that agile teams don't do Gantt charts. These folks want to know exactly when their project is going to be done... what it is going to cost... and what they are going to get for their money.

How do we respond to these people? Hey... agile can't be any worse that what we are doing now? Agile is all about trust... you just need to trust that this new way of doing things is better. Just give us a few sprints and we'll prove to you that this new way works. I promise, you'll like it.

Put yourself in that other person's shoes for a moment... your Product Manager was promoted and given big fat raises based on the insight and detailed analysis she put in those MR docs. The VP of Engineering got where he is today by making sure systems were designed fully up front. The Director of the PMO has built his entire career around applying the processes found in the PMBOK...not to mention the bonus he got for becoming a PMP in the first place.

These folks know something is broken... they know that we are making product development too hard...that is whey they let the team give this agile stuff a try in the first place. The problem is that... at the end of day... these folks are on the hook for making sure the organization delivers. When they are under pressure they fall back to what they know. They dance with the girl they came with.

It's important when we introduce something new that we spend some time figuring out what the people around us need to be successful. These folks have families... they have kids in college... they have financial obligations. You are not just asking them to change... you are asking them to put their livelihood at risk. People don't resist change because they are bad people or because they just don't get it. Chances are... at some level... they are afraid.

More than likely... there is some fundamental concern that you have not addressed. Until you understand what your detractors need to be successful... and work to satisfy that need... on their terms... they are going to continue to stand in your way. They will continue to hold you back and resist the changes you are trying to implement. If you had so much to lose... you'd probably do the same thing.

Trust me doesn't cut it until you have earned that trust. Agile will help you get there... but you know what... you might have to let them have their Gantt chart... you might have to let them have their MRD... until you can make it safe for them to let it go.

Okay... you're a few months into your agile roll-out. You did all the right stuff before you got started. Got sign-off from the execs... check... got team members trained... check... identified a pilot project... check... hired an agile coach... check. Why then... after all this time, effort, and money... are we still struggling with the fundamentals? Why can't we seem to get over the hump?

It seems that there is always someone... sometimes there are a lot of someones... that just don't seem to get it. They just can't let go of their trusted MRD... they can't seem to get past the idea that agile teams don't do Gantt charts. These folks want to know exactly when their project is going to be done... what it is going to cost... and what they are going to get for their money.

How do we respond to these people? Hey... agile can't be any worse that what we are doing now? Agile is all about trust... you just need to trust that this new way of doing things is better. Just give us a few sprints and we'll prove to you that this new way works. I promise, you'll like it.

Put yourself in that other person's shoes for a moment... your Product Manager was promoted and given big fat raises based on the insight and detailed analysis she put in those MR docs. The VP of Engineering got where he is today by making sure systems were designed fully up front. The Director of the PMO has built his entire career around applying the processes found in the PMBOK...not to mention the bonus he got for becoming a PMP in the first place.

These folks know something is broken... they know that we are making product development too hard...that is whey they let the team give this agile stuff a try in the first place. The problem is that... at the end of day... these folks are on the hook for making sure the organization delivers. When they are under pressure they fall back to what they know. They dance with the girl they came with.

It's important when we introduce something new that we spend some time figuring out what the people around us need to be successful. These folks have families... they have kids in college... they have financial obligations. You are not just asking them to change... you are asking them to put their livelihood at risk. People don't resist change because they are bad people or because they just don't get it. Chances are... at some level... they are afraid.

More than likely... there is some fundamental concern that you have not addressed. Until you understand what your detractors need to be successful... and work to satisfy that need... on their terms... they are going to continue to stand in your way. They will continue to hold you back and resist the changes you are trying to implement. If you had so much to lose... you'd probably do the same thing.

Trust me doesn't cut it until you have earned that trust. Agile will help you get there... but you know what... you might have to let them have their Gantt chart... you might have to let them have their MRD... until you can make it safe for them to let it go.

Subscribe to Leading AgileMike http://www.leadingagile.com

This Kindle e-book is written jointly by Pragmatic Marketing’s Steve Johnson and Enthiosys’ Luke Hohmann and Rich Mironov. It discusses the role of product manager in an Agile development environment.

No matter how agile Development is, you’ll never build a successful product if the work being done isn’t aligned to the company strategy and market needs.

A PDF version is also available on Pragmatic Marketing’s site.

The build master is a quite important role in an software development team. Responsibilities include ensuring the build works all the time and chasing down people who are fixing a broken build. Other items may include improving the build process which should also include the execution of comprehensive test suites in all test beds.

While on one hand it is a big help if a person in this role has prior experience with these tasks. On the other hand - and that doesn't have to be a competing goal - it is also valuable if team members take turns.

Let me explain. In all teams that I have coached I have found that different people have different strengths. For example one person might be excellent in writing Perl scripts while a different person is extremely proficient in relational database systems. By taking turns each individual can emphasize their area of expertise in the build master role. That way, if the skill is important to the whole team, the skill is also important for the build master role. Eventually all areas of expertise will get addressed eventually.

One more benefit of taking turns is that all team members walk in "the build master's shoes". There is a much better understanding of and buy-in by the team for build master related tasks and challenges. The response to being chased down because of a broken build will be tainted quite differently than if the same person is in the build master role.

At the moment I'm experimenting with swapping the build master role at the end of each release cycle (currently one month). And already the above mentioned effects have become visible.

Also check out "Manfred's DotNet Blog"

Agile Success Tour hits Atlanta. Next stop - D.C.

On June 25th, Rally hosted the Atlanta swing of the Agile Success Tour, where local software and IT leaders met to share Agile implementation stories, ask for advice and participate in group breakout sessions.

Catch the next event in Washington D.C. on July 23. The event is free, but registration is required.

Below are 3 themes that developed at the event:

1. Executing as a distributed Agile organization almost requires a tool

Many of the discussions focused on best practices for Agile adoption in a globally distributed team. One of the points that gained consensus among the attendees was that a distributed Agile team should use a tool as an ‘information radiator’. The tool helps to provide visibility into the teams iteration and release status regardless of where each team member sits and in what time zone.

Using a tool in a distributed organization helps to overcome some of the collaborative issues the group would otherwise face in the form of daily standups, blocking issues, and team velocity. Also, the group agreed that nothing goes as far toward team building as getting the team together – even if it is just once a year at the beginning of a release or to do retrospectives.

2. Agile can help quantify the case for additional resources – and understand why they are needed

My personal favorite discussion was when one group member asked “Does the team have to be a certain size in order to adopt Agile?” We thought he was assuming that a large team or organization would have a difficult time adopting Agile. Actually his question was based on the fact that his team was just two individuals.

As the discussion progressed, we all agreed that building a product backlog, then prioritizing and sizing the stories would allow him to articulate exactly what the two-some was capable of committing to in any particular iteration. If that much value was not enough in the agreed upon timebox, perhaps the business should consider more resources for this team.

3. We’d like to adopt Agile - how do we ‘sell’ it internally?

Many of the folks participating were anxious to get started – even before they came to the event. Where they were often getting stuck was in how to articulate the ‘why’ to the business.  Some great points that were shared were:

• Focus on the value of adopting Agile – and be specific. A recent study that was presented at the event highlights the fact that Agile teams are 50% faster to market and 25% more productive compared to industry averages.

• Agile represents a fundamental shift in our approach to resourcing.  How the work is organized will depend on what software you are developing, but the key is the team will create greater visibility about priorities, and put those decisions back in the hands of the business.

• Avoid using Agile ‘jargon’. Many people who don’t understand Agile will associate negatives with the words we all know and love: Scrum, sprint, backlog, user story – these are all Greek to non-Agile folks, and should be avoided when trying to gain buy in. Create associations and use well known equivalents as you gain consensus to move forward.

• With Agile, we focus on the shippable increment. This point should resonate well with the business.  When was the last time they got to see the product evolve every two weeks in demonstrations? One shared example from our executive panel was that the team would e-mail stakeholders an AVI demo every month. These folks could see the product demo (and it’s progress from one month to the next) on the plane, at their desk, on their own time. She knew success was at hand when the team didn’t send out a demo one time and an executive from the business called asking where his demo was – he was anxious to see it!

Further Reading:

• Agile Cuts Costs Through Productivity Improvements
• 12 Agile Adoption Failure Modes
• Product Owners Are Key - And 4 Other Lessons from Santa Clara
  

Recently at the Rails conference, Bob Martin served up a very provocative talk: "What killed Smalltalk could also kill Ruby." There has been a fair amount of controversy about this particular presentation, most notably from the Smalltalk community who consider themselves to be not-at-all-dead. They point out, for instance, that Smalltalk was not free "back in the day" and Ruby/Rails is, and that this makes more of a difference than many of the factors Bob was referring to.

For my part, I don't care all that much whether one language or another is in vogue as much as I care how the technology is being used and specifically how our profession is or is not maturing as a result. Bob said that we were not a profession in the past but are now. I tend to agree with him. He also equated the notion of a profession with the concept of disciplines which I also totally agree with (this should not be too terribly surprising to anyone familiar with the book I wrote recently - Emergent Design: The Evolutionary Nature of Professional Software Development - and if you note the particular engineering practices we choose to teach at Net Objectives).

So I'm with him on this, but I think there were a couple of things missing in his equation.

Being in a profession means many things. For one, there are standards and practices that all professionals are expected to follow. Lawyers save all documents. Doctors sterilize all instruments. But it also means that there is a defined way to enter the profession, and a set of support mechanisms that help the professional to succeed. The disciplined professional is provided with a helpful context in which to make the decisions that drive his/her activities, increasing the likelihood of success, and thus gains a fundamental degree of confidence in those decisions.

In other words, there's a lot in it for the professional to be in a profession -- guidance, which leads to confidence, which leads to a sustainable career. It's not so much about holding our feet to the fire and making sure we follow procedures (and slapping our wrists when we don't). Rather, it's about providing us with what we need to be extremely valuable to the people we serve. Isn't this ultimately what we all want?

In addition to this, the notion "professional" changes the expectations of those we serve.

For example, when I go to my attorney, I generally don't try to instruct him on how to solve a particular legal issue; I present him with my concerns and ask him what he thinks should be done. I don't dictate to my doctor how to solve my health problem; I describe my symptoms and ask her what she recommends we do about them. I also don't tell her how long it should take to solve the problem. How would I know? I trust her to know, if it's at all knowable.

When the customer thinks "professional," it changes their expectations regarding the interaction. I submit that, as software developers, there are a lot of times when we are told things we should be asked, and that this happens not because we don't consider ourselves to be professionals, but rather because we are not regarded as such by those we work for. But if we don't think of ourselves as professionals, why should they? And if they don't, should we be surprised when they tell us "this should take you two days"?

Furthermore, is it surprising that these arbitrary schedules are often at odds with reality? People who don't create software are understandably less knowledgeable about how it gets created, what the difficulties are likely to be, and how to best overcome them.

We need to start thinking of ourselves as professionals and to start behaving as professionals for many good reasons, but among them is that we will hopefully be seen as professionals by others, and this may lead them to ask us rather than tell us many of the things that can make a critical difference: what architecture to use, what process to follow, how and when to test, how to best document a specification, etc…

Of course, if we succeed in getting them to ask us these things, we'd better be prepared to give good answers. If my lawyer messes up, I hold him responsible… and I should. If we ask our customers to trust us at such a high level, they will expect us to deliver on that trust.

I submit that the things we elevate, as a society, to this level of responsibility and trust are the things we consider to be critical to our survival. Software didn't use to be that way. In my earlier career (in broadcasting), failure in my software did not stop the business from succeeding. We still stayed on the air. For many (most?) businesses today, software failures seriously hamper core activities and in many cases can stop the business it its tracks.

Put another way: agree or disagree with Bob on the idea that software is a profession. Whether it is or not, I think it needs to be and we need to get together on this conversation. What would a software profession look like? Should we have the AMA of software? Should software developers be licensed? How should developers be trained, what should the path of entry be to this profession?

Let's talk about it as a development issue and as a process issue…

-Scott-