The Definition Of Frustration

Demonstrating a killer, game changing feature, that no competitor can reproduce but not having a product to deploy it in.

Time for a cunning plan.

Trust

If you think you are working in an agile fashion but you cannot trust your team to deliver then you are not working in an agile fashion. The power of agile should allow the team to determine the best way to deliver project goals. If you find it necessary to micro manage every facet of the delivery procedure, then you are not doing it right. Sit back and relax. Have a little faith.

You Ain't Agile

The agile software delivery process can be many things. Essentially it is a process owned by the team that uses it, and should be adapted by the team that uses it, to make it best work for them. There is nothing set in stone, but typically you have quick iterations of software development, sprints, in which you deliver end to end functionality. If you can deliver that functionality to a Customer who can then use it, and provide feedback - brilliant. You can then act on the feedback.

At the end of each sprint the team should take time to reflect on what they have done, and see how they can improve the way they work, in order to make their lives easier. Not the lives of their managers, but their lives. These sprint retrospectives are an incredibly important part of the agile software delivery process, as they allow every team member to express their thoughts on what went well during a sprint, and what did not go well. The team can then celebrate what went well and reflect on what did not go well, and define a mechanism to make sure the things that didn't go well improve moving forwards.

It's important to understand that it is the team that owns the agile software delivery process, so it should be the team that decides how to best implement it for a specific project. The team should be empowered to make whatever change they feel will improve their lives based on discussions held within a sprint retrospective. A retrospective is not a witch hunt, it is an open, and sometimes frank, discussion about how, as a team, you can work better together.

So if you don't have retrospectives at the end of a sprint, there is no mechanism to calibrate within the team. There is no mechanism to allow team members to provide feedback as to how well they feel the team is working. There is no feedback to allow team members to suggest improvement. If you don't have retrospectives - there is no way to improve. If you think your software delivery process is fine as it is, then the chance that you are wrong is huge. Nothing is perfect.

I don't care how many two week sprints you deliver (or not as it may be), if you don't have retrospectives and allow for team evolution and growth, then you are missing the point of agile. One thing is certain working in sprints isn't what the process of agile software development is about. If you refuse to allow your team to improve, because you think you are right, then you ain't agile! You are about as agile as a brick.

Cheers

The Iceberg Software Development Process

When you struggle through a waterfall software delivery process, in almost every case you will take a massive iceberg of an idea and end up delivering a tiny melting ice cube.

This is of no use to anyone, unless of course you have a nice glass of gin and tonic. Even then though you will need a lemon .... oh wait, typically if you follow a waterfall software delivery process you will have one of those on your hands as well!

Waterfall Software Delivery - favoured by gin and tonic drinkers everywhere!

Sprinting Up A Waterfall

A sprint, in Agile software development, is a period of time in which the scrum team attempts to deliver end to end user stories. These user stories should be demonstrated at the end of the sprint, to whichever stake holders are interested, at the end of the sprint. Simple. In fact it's a very simple concept to understand.

What a sprint isn't is a period of time where you develop user stories in isolation, and not demonstrate them at the end of the sprint. It is not a period of time where you continue waterfall style development and upon completion say you haven't finished yet. If you are working this way then you are not working in an agile fashion. Simple.

When Do You Acknowledge A Project Is Poison And What Can You Do To Find An Antidote?

There are certain software projects, that if mismanaged spiral towards mediocrity very quickly. Why do they not spiral toward a certain death? This is because in the end, most software projects deliver something. They may not deliver the product vision, but through all of the pain the team end up delivering something.

Why do I think these projects are poisonous? It's simple. In almost all cases no-one likes using or engaging with a mediocre product. Customers love using, and love sharing, products that exceed their expectations. Mediocre software deliveries rarely exceed Customer expectation and consequently rarely get used by the end Customer they were intended for. Sure there is the odd occasion that a mediocre software delivery is loved by the intended Customer base. This is rare.

Also mediocre products are rarely loved by the people that create them. If this is the case then the software delivery team will rarely promote their own work. They will rarely be proud in their work and in most cases they won't have an interest in taking ownership of their work. A sense of ownership within a software delivery team results in actually allowing the team to engage and grow with the product they they can then strive to improve to exceed expectations.

So how do you determine if your project is poisonous, and how do you deal with it spiralling towards mediocrity? A really clear indication would be if several, or indeed many, of the delivery team leave during the project lifecycle. This really should set alarm bells ringing, and theoretically trigger a response. Clearly acknowledging there is a problem is the start to finding a solution to solve it.

A group of people leaving a project is the clearest indication of a poison project. A pretty simple way of finding a possible solution in this case is to ask the people leaving what they think would solve the problem. even ask them if there changes were instigated would they consider staying? Who know's it might be the kick start needed to lift the project above mediocrity.

As an example in a previous occasion when a number of people left a project that I knew about, they mentioned that communication with marketing and stake holders was a continual problem and that no matter how much they tried to solve the problem they met brick walls that they could not overcome without further support. A simple solution here might be to sit the delivery team e.g. marketing and technology together. If this is done communication is no longer a process but rather an instinct. It is almost impossible for a team that sits together to not communicate better! If communication is an issue, remove barriers that are making it an issue. In this case what would there be to lose? Things cannot get worse!

Another means to determine if a project is heading towards mediocrity is to simply ask the people who are working on it if they are happy. If there are then it's a pretty safe bet that the project is adding to their level of well being and this typically would indicate a measure of future success on the project. If the team on a whole is down, then rest assured something is wrong with either the product or the process that is being followed to deliver it.

What can be done to fix this? Well the answer is simple again. Let the team decide how to fix it. A delivery team, in most instances, doesn't need to be directed from on high. A delivery team, if correctly staffed with the right level of experience, knows what it has to do to get something out the door. This is where the beauty of the Agile software delivery process comes into play. Agile promotes self inspection by the team who own the product and delivery process that they are working on. If things are not working correctly, then the team, not an individual, decides on the best approach to improve.

Two Sides To Every Coin

There are always two sides to every coin. I guess that is unless you have a one sided coin ;-). Firstly though, what is odd about the above coin?

So this morning I was reading about the Valve Employee Handbook. There are a lot of common sense solutions to the way the promote how they work and seemingly a lot of trust given to employees of Valve! If you have been asked to work there, seems they believe in you, and let you get on with whatever you feel you have to do to best provide value for the company. 

On the other side of the coin though, there is the environment in which trust is not felt as a necessity to empower employees to deliver a result.

Reading both of these after each other provides stark contrast of two very different working environments. I would suspect that only a sadist would be truly interested in the description of the second working environment! The reaction of the blog-sphere and on twitter would lead the casual observer to believe that most people would prefer the Valve method of getting product out the door ;-)!