I recently wrote a short article on AgileScout.com focusing on questioning our existing habits and practices. In my opinion it’s easy to miss poor working routine and processes. Its important that people don’t stop questioning why certain processes or procedures are in place. Just by questioning some of these habits and processes could save time and improve value and is in the direct control of most people undertaking the tasks. I feel we should always question why we are doing something to make sure we should still be doing it. Have a read and see what you think : http://agilescout.com/teams-over-processes-dont-be-insane/

Day 1 Tuesday 11th October

Keynote introduction

In a very large conference room occupied by what I presume was over 350+ people, the introductions began. Nigel Baker, and Carol McEwan the event organisers gave a relaxed, funny and informative introduction to the day by answering a few assumptions, introducing the conference and defining the structure of the forthcoming events.  They also reassured everyone that the third day “Open Space” would be something to stay around for.  The mood was good and the room felt like we were all horses lined up to start the grand national. And now onto the keynote speaker…..

Day 1 – Keynote : Managing a collaborative multi-national team in real-time using Agile/Scrum/Lean/Scrum/XP (Building a 100mpg (approximately 158mpg UK Imperial) Road Card in Three Months)

Speaker : Joe Justice – Wikispeed.com @wikispeed

I have to confess I didn’t know what to expect form this talk, although the topic surely did sound interesting. Having sat through the conference, I’m very glad this was selected as they Keynote. Joe gave a truly inspiring presentation which set the tone for the entire conference. Wikispeed.com managed to really build something amazing in just 3 months with limited budgets, time and resources. Not only that, they managed to beat down many of the well known giants in the automotive industry, who in comparison have infinite resources and experience(in theory anyway). His story of how it started in his garage with a small team of volunteers, together with their accomplishments was inspiring! Those of us familiar with software engineering can parallel his approach by creating modular components which enabled low costs tooling, ability for rapid change and most amazing of all he somehow managed to create TDD like approaches to the car construction using physical indicators for all the teams (Green/Red lights on the wall)! I mean, Wow! Not only is this car continuously improving, but it can change it’s whole properties in a matter of minutes at incredibly low costs and still maintain its objective of 100mpg and apparently it can do 0-60mph in 5 seconds!

Although this is, and still is an exciting on going endeavour to which wikispeed.com will go from strength to strength, it wasn’t just so much the car that impressed me, moreover the passion and vision of the team. It takes some courage and true grit to take a few volunteers and take on the worlds leading motor manufacturing companies. The dynamic way in which Agile practices are applied, the way in which teams of all different skills (all levels welcomed) work together, continuous improvement practices and generally the way the teams work together is amazing! So many examples of Agile in practice are software based which is more often or not virtual products, seeing (pair programming) ideologies in practice with people all snuggled under the bonnet of a physical product, really demonstrated the Agile approach. I don’t think there was one person in the room who wasn’t inspired, a great start to the conference.

Day 1 – Session 2 : Sin or Salvation – Using Kanban to Prepare a Scrum Project

Speaker : Roman Pichler – @romanpichler

I think most people reading this session title would be like me, very intrigued. I mean why use Kanban to plan a Scrum project? As I have read and seen quite a few books and presentations by Roman Pichler, history tells me that this would be a good session.

Planning and/or starting any project is often one of the most difficult parts. Its during this time, projects get the green or red light. From personal experience this can be a very disjointed, opinionated and dangerous part of a project.  Some great ideas don’t survive because they are not great ideas, but sometimes just because the spark didn’t ignite through a bad start. This presentation suggesting to use Kanban to plan a project made a lot of sense. The interactive, structured and visioned objectives as suggested during this presentation offered a clear and structured approach which certainly would be advantageous in my opinion. I liked the way in which Roman Pichler demonstrated moving ideas through the process, working with multiple people through the WIP limits and offering prototypes/inceptions to be assessed by stakeholders. This presentation was well argued, demonstrated and gave me a lot to think about, some of which I will be looking forward to try.

Day 1 – Session 3 : Facilitating Creativity for Breakthrough Problem Solving

Speaker : Darian Rashid – @darianrashid

Why I chose this session was simply for the fact that it tackled creativity. Creativity is a key component to any and every project. Great ideas whether that be the product one is working on or the simple elegant solution to one of the thousands problems that might surface everyday requires creativity.

A couple of moments in just as I was getting comfortable, Darian started speaking and I have to say I thought he could be a little crazy (In a good way of course). I then realised that choosing anything with “Creativity” in the title during an Agile conference was going to involve getting up an moving around. Well Darian insisted that we trust him on what would be an adventure and we had no reason not to.

After a couple of moments of self-organising into small groups, we found our personal space and started tackling the tasks set. We were given an interesting scenario where we had to save people form the sinking Titanic, a good metaphor for some businesses. An interesting scenario which progressed onto other tangents such as listing the attributes of a banana. We all went with it and started listing more and more, becoming more elaborate at each task. The exercises were driven to apparently make the mind more “rubbery” which would lead to creativity and horizontal thinking. We then progressed onto the final task which was to sink the Titanic as fast as we could and limit the number of survivors. For some concerning reason, everyone in the room was much better at this! Some of the solutions would have been worthy of Hollywood, but it was fun and all in good taste.

Having gone through the very interactive session, the exercise was a real success. The path Darian led us down demonstrated alternative routes and exercises for creative thinking. I have and still am thinking of ways to apply this as it could be very powerful. A fun session which gave everyone food for thought and opened new doors to creative thinking.

Day 1 – Session 4 : Maximising Sustainable Pace : How Teams Raise Their Own Bar

Speaker : Bob Sarni @bobsarni – BigVisible.com

This appealed to me as sustainable pace, whilst often increases velocity in my opinion something that should be taken seriously. Not understanding sustainable pace could lead to disaster. I have seen both sides to this where brilliant teams progress when sustainable pace is achieved and other teams decrease where unsustainable pace has been imposed often by those who see people as resources.

This was quite an intimate and interactive session. I was pleased to see that when sustainable pace was broken down into the perceived elements it wasn’t just methodologies such as XP that were listed, but also more social factors such as happiness, teamwork and trust. The elements were broken down in a similar fashion to the “5 Whys? “ but using “Hows?”. It created good discussion and was quite thought provoking.

A real ice breaker and an informative example was the strategic inclusion of a short video of a comedic therapy session between what I presume was a psychiatrist and a patient. This was really funny and demonstrated the point of focus and direction well. I think I’ll remember the two words “Stop It!” for quite some time. If I manage to find the video link, I’ll post it here.

Scrum Cruise

A great way to finish the first day, the generous sponsors VersionOne and Betfair had arranged for us to take on the pleasurable Boat Cruise “Dixie Queen” on the Thames. This was a great way to unwind, reflect on the day and engage with others at the conference. With a food, beer and entertainment, this event went down very well. I think it’s safe to say that everyone enjoyed this and there was some great conversation going on in every corner.

I think it was safe to assume, Day 1 at the conference was a huge success.

Day 2 >>

I recently submitted another post to AgileScout.com, discussing the ever changing routes of project. There is still a natural habit for people to assume they can predict the future and plan projects in creative environments. Agile is about working with change and following value. If you are interested, pop over to AgileScout.com and have a read.

Recently I got talking to an old friend ad the topic of good programmer books surfaced. This got me thinking, what books have made a difference to me and what books would I recommend to others. Obviously computing is a vast topic and in the past few years my main focus has been on development teams, production environments and software from a businesses perspective. However as a developer there are few select books that have stood the test of time, that I think back to and often pick up. These are the books that I feel have added value to me and that I would recommend to others :

1. Design patterns : elements of reusable object-oriented software

This book needs very little introduction. Published in 1994 by who are now knowns as “The Gang Of Four”, this was arguably a revolutionary book to the computer industry. Although some came before it, this was well written text addressing “Design Patterns” and addressing the common structural patterns and obstacles using OOP. Any programmer worth his salt would have read, owned or would have encountered strong reference to this text.

2. Patterns of Enterprise Application Architecture (The Addison-Wesley Signature Series) – Martin Fowler

Martin Fowler, a living legend in the programming world, wrote another fundamental text for programmers. It breaks down and explains common design patterns and software architectures in a detailed and very informative ways. He explains common structures such as MVC amongst other things. This is the kind of book you own and refer to many times through your career due to it’s clear insight and understanding on the topic.

3. Code Complete: A Practical Handbook of Software Construction – Steve McConnell

I was a little late coming to the party on this one so have the above (published 2004) in my collection, not the original publication 1993. However for obvious reasons the latest version would be recommended. This is a really in depth text and is surely considered one of the most useful practical guides to programming. This book is a heavy, but very informative reference for anyone serious about their craft in software engineering. Full of insights from cover to cover. I suspect most people recognise and will recommend this text somewhere along the line.

4. The Mythical Man Month and Other Essays on Software Engineering -
Frederick Brooks

This is a classic project related computer text which has been referenced extensively over the years. A great read with extensive insight into the workings of the software environment. Not only is this informative, I have to say I found it quite a fun read with very witty examples. Some famous analogies are derived from this text including : “Brooks illustrates the fallacy of adding workers to speed the work by counterexample: If one woman can produce a baby in nine months, then nine women should be able to produce a baby in one month.”

5. The Pragmatic Programmer: From Journeyman to Master – Andrew Hunt, David Thomas

Originally lent to me by a close friend, I was pleasantly surprised to read this book. Really well written with shared experience when working within computer environments and craftsmanship. It was this book that taught me how to cook “Stone Soup”, a recipe that has helped me and others in many difficult situations in getting ideas understood. This book helped me understand and appreciate programming as a craft and a little more n the environment within.

6. Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin

I have to be honest I have not read this book cover to cover. However I have consulted it many times as a reference and when picking it up, it’s difficult to put down. A really good read for anyone who in the working environment. Its inevitable that you’ll come across bad code smells even if your working in coding utopia. This offers practical guidance on how to work as a respected crafstman in such areas.

7. Head First Design Patterns – Eric T Freeman, Elisabeth Robson,Bert Bates, Kathy Sierra

Some of you reading this will probably be wondering why I included this book in amongst the other greats above. I have to say I really took a liking to this book for the reason that it took the somewhat serious and sometimes theoretical subject of design patterns and injected some life into it. The fun, practical approach of these authors really made the subject more enjoyable to read. For anyone who might see design patterns as a heavy read, give this a try. You can even use some of the ideas to have some fun with your peers.

8.Domain-driven Design: Tackling Complexity in the Heart of Software – Eric Evans

I have spent more time in reference to this book than actually reading linearly. There are many presentations online covering or referring to this text. Eric Evans expresses the need to relate your problem solving abilities with the domain in which your working. The relationship between the domain and the solutions one provides, should be strong with good awareness of your working domain. This will not only help you personally, but drive innovative solutions into the production environment. To put it better : “This book belongs on the shelf of every thoughtful software developer. –Kent “

Additional Suggestions

Working Effectively with Legacy Code- Robert C Martin

This book provides programmers with the ability to cost effectively handlecommon legacy code problems without having to go through the hugelyexpensive task of rewriting all existing code. It describes a series of practicalstrategies that developers can employ to bring their existing softwareapplications under control. The author provides useful guidance about how touse these strategies when refactoring or making functional changes to codebases. One of the book’s key points is that it teaches developers to write teststhat can be used to make sure they are not unintentionally changing theapplication as they optimize it. Examples are provided in Java, C++, and Csharp,and the book assumes that the reader has some knowledge of UMLnotation. Strategies using UML and code in C++ and Java primarily whilelanguage independent advice will be delivered in side bars and appendices forlanguage specific users. – Amazon Review

Refactoring: Improving the Design of Existing Code – Martin Fowler, Kent Beck,John Brant,William Opdyke,Don Roberts

	Your class library works, but could it be better? Refactoring: Improving the Design of Existing Code shows how refactoring can make object-oriented code simpler and easier to maintain. Today, refactoring requires considerable design know-how, but once tools become available, all programmers should be able to improve their code using refactoring techniques. – Amazon Reference

A full reading list would be quite extensive so this just provides a starting point of the main titles. I have tried to keep them more programming specific than Agile, so maybe I’ll add a second list to this blog in future.

Feel free to offer some feedback or suggest some titles that you think should be added to this list. Books which have influenced you and that you would recommend to others.

So you have a product backlog consisting of a nice list of user stories which have been loosely estimated by the team, and a team nearly ready to start ploughing through the exciting journey to building a product. You’re under pressure to get a deadline announced. What to do next?

Well at this point, I presume you don’t know the teams velocity as they haven’t started the project. Ideally the first thing to do (if possible) is to get one or two sprints done to get an idea of the teams velocity. You might be thinking that you know the teams velocity as they have just finished another project and it’s the same people. Don’t make the mistake of cross-applying the velocity to the new project. Each project presents different challenges and can be vastly different. If you presume to carry this over, I’m confident that you may be in for an unpleasant surprise!

After one or two sprints, you’ll have a rough starting figure from the velocity, or at the very least a list of problems which could drastically identify any fundamental issues missed during the product backlog derived from the retrospectives. Assuming you now have a velocity, you have your first step towards announcing a deadline.

Lets set the scene and say you have 1000 points in the product backlog and a cross functional team of 4 people to keep things simple. Your average velocity after the first two sprints is 100 points per sprint. Therefore you would be tempted to state the release backlog should be 10 sprints. At this point you might be thinking “Well I know that because we do retrospectives, and remove impediments, the team gets faster over time so I don’t need much of a contingency as the increased speed will give me some slack”. Don’t be tempted by this, it’s worth putting in a contingency as it protects yourself if your the PO and aligns business expectations. If you are ahead of schedule at the end, people are not generally going to be disappointed to hear you’re ahead of schedule or that you can develop more in the anticipated time frame.

Working out contingency can drastically vary between projects, companies, teams and environments. Depending on your knowledge and risk management strategy this can range from 5%-50%. A few things that I consider when calculating this, some of which have emerged from my own personal mistakes are :

1. Consider increasing contingency when working with smaller teams. In the example above with a small team of 4, it’s not unlikely that one or even two people could leave during the project. That’s at least 25%-50% of the workforce gone. If you have many teams totalling 100 people, it’s unlikely you’ll loose 25%-50% of the workforce at exactly the same time.
2. Consider the “Focus Factor” (A term I have borrowed from Henrik Kniberg : http://www.crisp.se/ScrumAndXpFromTheTrenches.html). Putting it simply, consider factors that could interrupt the teams concentration and commitment each sprint. The more of these, the lower the “Focus Factor”. The lower the focus factor, the lower the velocity and so forth. I suggest reading the above book for more depth on this topic.
3. Account for absences and holidays. Even if you are looking ahead for the next 8 months and nobody in the team has holidays booked, this is not to say they won’t appear later down the line. Failure to account for these could be detrimental.
4. Account for “White Noise”. The PO’s role is vital for the team to work in priority with enough detail and direction. If the PO is absent or distracted, there is a chance that the some focus will be lost for the up and coming user stories; similar to the “Focus Factor” mentioned above, but more related to the PO. This could be as a result of other business activity, sickness or general distraction from stakeholders.
5. Consider that the less you know, the greater the risk. When you have identified what you consider to be the likely risks, remember that contingency is to account for unknown risks. Always include a metric for completely unknowns which are not part of the above, those which could be categorised, but not detailed.

All of the above considered should present you the path to calculating a contingency. Don’t be alarmed to see high rates of contingency such as 25%-50%. It’s better to be truthful in the long term rather than tell people what they want to hear in the short term and fail. I sympathise that you can say next September and some people hear next June, but that’s their input not your output.

Another factor worth highlighting here is that contingency isn’t necessarily a buffer for additional work. This is the case with the fundamental Agile philosophy of welcoming change. Change should always be welcomed, but contingency is not part of a project to insert additional work. If we have 8 months to deliver a product backlog with 1000 points with a 25% contingency level, the contingency is there to deliver 1000 points, NOT 1250 points. Therefore the PO should note that if during the sprint review new requirements emerge, these should be estimated and prioritised, but not inserted into the product backlog without consideration to the existing commitment. The additional story should either replace an item of lesser priority within the backlog of the same estimated value or if all is required for the version release, the deadline should be extended to accommodate the additional work and the stakeholders informed. Being transparent about this often helps truly prioritise the change in its true scale. Failure to remember this, will put pressure on the team and increase the risk of failure.

Contingency is often within the projects to account for unforeseen circumstances which are not part of the original project plan. If you overestimate the consequence could be an early release or undertaking more features than agreed to in the same time frame which is often received well. Underestimating on the other hand, lowers moral in the team, invokes lack of trust and lets the stakeholders down which could be very costly for everyone. Build in and plan the contingency well into the release backlog and remember that saying yes in the short term to tell others what they want to hear is counterproductive and high risk for the PO.

Image: renjith krishnan / FreeDigitalPhotos.net

For the past few months I have been involved with trying to refine some of the procedures in our Scrum teams. This is an on going process which always deems to be worthwhile. Obviously one of the natural activities which is the “retrospective” helps a great deal in identifying problems that need some attention which could be affecting production.

One of the most common conversations I hear with varying depth is where the team discusses issues (business functionality) that aren’t really problems, but they think are to some degree. They can spend valuable time worrying or debating such issues. What this is referring to is where the team will discuss items which they feel should exist, but do not. These are items the team didn’t commit to in the previous or current sprint, are not in the next sprint and in some cases not even in the whole product backlog. However the team feel that they should exist and question their existence, not bearing in mind that they might not exist for very good reason. The team should however be encouraged to ask the question, but also respect the answer if it validates its lack of existence.

Production teams are naturally innovative and if you have done a great job in setting these teams up, they will have a strong sense of ownership for the developing product and will want to add as much functionality as possible. Although these great ideas and high levels of enthusiasm are fantastic properties of the team, left uncontrolled they could cost the product a great deal and in some cases could cause a product to fail.

The Product Owner should really define and focus the “What” and “Why” in the product backlog. The team take these and decide on the “How”. This should not by any means create a sharp divide between the team, but an understanding of the product backlog priorities. A good Product Owner will often utilise the team to create “managed” innovative ideas which could add brilliant features to the product backlog with a large value to the end user. The Product Owner should communicate value to the team for each of the sprint goals.

Value isn’t measured by having the most features you can get in a short time, but by having a balanced product which is exactly what the user wants to satisfy their needs and goals. Therefore refining an already well used feature could add more value to a customer than by giving them a brand new “bells and whistles” feature instead of.

In short the Product Owner needs to take sole ownership of the product backlog. They should be communicating with the team as well as the stakeholders what features are being developed, when and why. The team can provide a great deal of input, and features can evolve from such input. However it’s the Product Owner who is the “ringable neck”; so getting a product in the right order and answering the “What” and the “Why” is explicitly in their interest. Production teams need to trust the Product Owner’s decisions and the Product Owner needs to work with the production teams to earn that trust. When that balance is found risk of change is reduced and production values can increase. Then the balance of responsibility for answering the “What”, “Why” and “How” is maintained.

I am fortunate to work for a company that is growing extremely fast, right? Although that sounds great, company growth can be a very destructive force indeed. With growth you risk losing control of your every days tasks which you take for granted, such as assuming everyone knows the best practices and procedures, direction of the team, where to go for help, quality, limited interruptions etc. Rapid growth in teams can be a very time consuming and a very uncomfortable experience which can be costly to the business. Brooks’s law rings ever true : “Adding manpower to a late software project makes it later”.

A very inspiring book I read a few months ago that I highly recommend to anyone interested in a development mindset is “Rework”. A passage within this book resonates as one being told by very wise men who have experienced the problems with rapid growth :

“The right time to hire is when there’s more work than you can handle for a sustained period of time. There should be things you can’t do any more. You should notice the quality slipping. That’s when your hurting.” – (Rework: Jason Fried and David Heinemeier Hanson)

That said when you only expand when absolutely necessary you should be aware that extra attention is needed in the right areas. Using Scrum, we advocate smaller teams with better communication. This helps people progress quicker and teams to be become more independent and responsible, which ultimately leads to increased productivity.

When we start new projects or reshuffle teams, we try to keep sprints short (1week) until the team settles with each other and then open it up to 2 weeks. The main advantages of this is that it puts pressure on the Product Owners to ensure that the tasks are small enough to tackle over a shorter time frame and therefore increases the quality of user stories, but it allows us to have weekly retrospectives which gives the team time to flush out problems quickly. The retrospectives quickly identify the bigger problems and these problems can be identified and removed quickly as a result.

To put this in context, recently a team I was managing went through a lengthy process of retrospectives and a small but obvious problem began to surface. The team although situated very close (split between 2 rooms divided by a glass wall with an open door which I sat between) was starting to highlight a divide. I believe this was partially based on skill set differences and partially based on new members joining the others. However one obvious problem was that the divide was being reinforced by using instant messaging tools rather than face to face communication. Divides like this must be identified and dealt with sooner rather than later as the problems can escalate very quickly.

To tackle this problem I thought of a principle of the Agile Manifesto which was :

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”

I instantly made changes to factor this in. I moved my desk out of the way into another room and made sure the entire team sat next to each other with no exceptions. I explained to the team why this was done in line with reinforcing if an individual does a great job, but the team as a whole fail, everyone fails within the team and vice versa. I only look at the success and failure of the team not the individuals within (there are other processes involved with this outside the scope of this post).

Following a very productive retrospective and now with an environment which eliminated the need to communicate using anything other than face to face communication, there were instant benefits. I am not exaggerating when I say there has been an increase in productivity close to 200-250% seen within the first week and this velocity has been sustained! (There were other issues raised within the retrospective which attributed to this growth as well, but without doubt co-location was a major contributor).

This to me clearly demonstrates the impact of small often unseen problems within production environments. When teams expand, an effort should be made to ensure the teams are working close and communicating well. You don’t need to physically be involved with the teams as you will get in the way, you need to clear the path and facilitate the platform to highlight problems. I believe excellence is a living entity that you need to keep striving for and analysing. You should be aware of the impact of environmental changes and aware of the dangers/benefits when expanding or moving teams.

Product Management or Product Ownership, depending on how you title the role embraces a role which should be filled by a person who acts as a visionary. A visionary is not a person who acts as an oracle of all things wise, but someone who utilises all the knowledge around them and makes what is perceived to be the most valuable decision whilst balancing risk. Depending on the person, he/she will determine how the product will evolve to be the best it can be in the market place (sometimes doing less is more valuable). This involves communicating a great deal with ALL those involved with the product and/or market including, but not confined to engineers, designers, UX specialists, stakeholders, end users, competitors and so on. Gathering knowledge can be intentional such as creating user group sessions, analysing successful products within the market place, but it can also be unpredicted. Rapid release cycles and analysis of customer feedback can steer products and lead to rapid innovative techniques which embraces customer centric development. I believe this to be the way in which Google often approach their development and their success needs no introduction.

It’s human nature to want to categorise everything, but in my opinion it’s unwise to restrict oneself to a methodology such as “Product Centric Development” or “Customer Centric Development”. Two favourite quotes of mine highlight the balance of product management and the role of a visionary.

“If I asked my customers what they wanted they would have said faster horses – Henry Ford”.

“People don’t want to buy a quarter inch drill they want a quarter inch hole – Theodore Levitt”

I personally feel that a product manager/owner should find the balance between Product Centric Development and Customer Centric Development to create great products. Sometimes this means you will have to make decisions which solve the core problems of customers where the “how” is the key innovative feature. By involving all in the brain storming sessions and continuously analysing the market from all angles, the direction of the product should discover new ways of doing things whilst successfully meeting the customers needs. The engineers will highlight whats possible with current technology, the stakeholders will facilitate the resources required and customers will tell you what problems they want solving.