Craig Strong

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.

I have recently established a link with the AgileScout.com regarding contributing more to the online community. Therefore most if not all my Agile specific articles will be posted on there in future. The Agile Scout is a very well respected online resource for the Agile community and I am pleased to have the opportunity to contribute where I can.

I will add the links to my posts on AgileScout.com here when these posts are made, but I will not be duplicating the content here.

My most recent post which I hope you will enjoy can be seen here : Agile – Depth Within Simplicity

I will still be posting articles on c6s.co.uk regarding other topics such as management, production, development and general technical encounters etc.

Thanks for reading.

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.

When first introducing scrum into the workplace some time ago, many people had strong
views on what agility meant and certainly had some strong opinions on how Scrum should
be implemented. Some of these views created divides between teams, people and
processes. After quite some time re-factoring processes, communicating and refining
techniques everything started to take shape. We started getting to grips with TDD, had a
continuous integration server set-up, introduced product backlog tools to manage groomed producted backlogs and really
progressed well with the quality in writing user stories. In hindsight it was clear that what
we started with was far from what we needed and ended up with.

Although we seemed to follow the standard practice well and could see progress all
around, the first and largest project we started which was the project we introduced scrum
to the company with, was late and far from agile. Management had little confidence in the
project and were concerned that every time a change was made, bugs would surface into
the product backlog. Not only was the management concerned that change was
problematic, but confidence was so low that there was a fear that introducing new features
would put the launch of existing features at risk due to the possibility of new bugs
surfacing. This was not a good place to be for anyone!

Looking at this project many things went wrong, but most had been fixed. After a few root
cause analysis exercises we looked at the main symptoms. It was quite obvious the main
reason it was late was because the project developed an incredibly long tail of bug fixes.
“How could this be?” we asked ourselves, we have TDD in place, we have peer reviewing, a
pretty decent “done done” list and a few other XP practices in place. We knew bugs would
always surface as this is the nature of software, but this was a case where you fix one bug
and introduce three more. I began investigating the problem further, this was clearly not
the way to do it! I regained my title as Scrum Master in the problematic project and started to observe the team.

After a few hours I started to see the root cause of the problem. When the team were
tackling the user story they would notice bugs. However the bugs were “not directly
related” to the user story being worked on. As a result of this, the team would look down
the backlog and see a user story which covered the area where the bug surfaced. Then
they would negotiate with the product owner not to fix the bug in the existing user story, but
to leave it there and fix it when that user story surfaced. Apparently this would be quicker and it was a way to by pass the failing tests and negotiate a way around the “Done Done” list. After seeing this the penny truly dropped.

The problem with the above was that we were using an agile process with a waterfall
approach to the product backlog. After each retrospective taking this approach meant the
product was not shippable and the sprint reviews would introduce new directions for the
product. What this meant was that the user stories in the backlog which would fix the accepted bugs, may be removed, de-prioritised or never tackled. Therefore this meant that additional user stories had to be created to solve the debt which should never had been
there or that velocity would continuously decrease due to an ever increase bug debt.. The value of these user stories was very low. This exposed the fragility of the process and  also enforced why it is so important to ensure each user story is shippable by adhering the a clear, well defined “Done Done” list.

Following the identification of the above, we came up with a strategy to resolve the issue.
The Scrum Master (Myself), had to enforce a strong bug stance in accordance with a more
detailed “Done Done” list and flush the bugs out. Initially velocity went down considerably, but it was a
true velocity. After a few sprints not only would the bugs be flushed out, but the product backlog was much healthier. Managementʼs confidence started to rise again and although less was being delivered, what was delivered was shippable. After just a few sprints velocity started to rise and the long tail of bugs added to the product backlog started to diminish.

To conclude, we learnt at our expense that quality is a metric that is controlled by the team
and expected by the client. Putting off today what can be done tomorrow is not the path to
agility especially when this is quality. Doing so will increase the likelihood of project failure and make the product fragile.  The product backlog is a living entity subject to
constant change. Unlike waterfall the path is not linear and if it is, the path is not agile.

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.

In the past few years I have read about Scrum, Agile and watched many a tutorials and short videos on the benefits and how to implement it in the work place. After watching from a far I managed to get my hands dirty and get involved with applying it in the workplace. Over a period of many months, bit by bit we have implemented it into our development environment. I have to say it hasn’t been easy and it’s only possible with support from the business in my opinion. Developers and testers were the first to welcome the change as it empowered them and gives them recognition for their efforts as well as control. The business took longer as the change is drastic and involves them a great deal more in product development. However once involved, the agility and development speed and project transparency becomes something recognisable and desired.

During this implementation a common emphasis raised via many sources is to keep the teams small and focussed. Many comparisons have gone through my mind, including why and how to select certain people and create teams. One of the best comparisons and inspirations to make sense of this is to compare the military structure. The comparison that strikes me is that traditional waterfall teams which consist of large scaled divisions that progress in linear fashions with a great deal of resources and structure. They take a great deal of planning, authorisation and strategy to get momentum. When the momentum has started, it’s difficult to stop and change direction. These can be compared to a military invasion, invading in stages as one large force following months of planning and financial investment all moving towards a strategic location in mass. Scrum teams to me represent a different dimension to this, I see scrum teams as small, more precise well equipped units similar to special forces. Smaller teams which are empowered, focused and take more control over their missions who often find themselves more capable and agile. They can be deployed into many different environments, are quicker to adapt and are in and out of missions quickly, sharply getting maximum results.