Featured Post

Planning by value alters the routes of projects

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,...

Read More

Questioning the value of existing processes

Posted by Craig Strong | Posted in Development Practices, Miscellaneous, Scrum / Agile, Software Development | Posted on 28-12-2011

0

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 2 Scrum Gathering London

Posted by Craig Strong | Posted in Miscellaneous | Posted on 18-10-2011

1

Following another briefing from Nigel and Carol, we reflected on the previous day and the structure to the day ahead. There was some very minor changes to the schedule and all was in order. Onto day 2…

Day 2 – Keynote : Making the Entire Organisation Agile

Speaker : Steve Denning @stevedenning

10 Year Growth/Decline

10 Year Growth/DeclineChange or Die

I was really looking forward to this presentation more than most. Having read some of Steve Denning’s work, I am an enthusiastic and very keen to hear his next word.  He was quite a big name to have at the conference and his depth of knowledge is very well respected world over to say the least. Well he didn’t disappoint. I’m sure that he is a very accomplished and experienced presenter, but what I most of all enjoy is the hard facts and direct approach of the presentation. Quite simply, the world has changed and those who are not on board will die out faster than you think. He touched on the story of “Why Amazon can’t make a Kindle in the USA”, focused on the message that the “customer is the new boss”,  and presented concerning hard facts about the rise and decline of some of the worlds biggest companies. Steve presented an alarming, but reenforced statement that by 2020 more than half the fortune companies will be new companies.

Finishing the presentation early gave room for some interesting questions from the floor. Some interesting and fun discussions enlightened the listeners and gave lots of food for thought. One thing in particular that stood out for me was the ability of change. Reenforced with references to the text “Change or Die”, most people chose to die over change. With a few discussions emerging around this fact, it was disturbing and at the same time reassuring to know that some people cannot be changed. In fact even faced with certain death whether it be personal or business, research indicated that the majority would choose their own demise. Therefore sometimes for companies to survive, sometimes its required that the very people at the top need to be removed or replaced. An interesting fact which I’m sure takes a lot of peoples energy and effort when trying to help protect businesses.

Overall a great presentation as expected, from another truly inspirational leader. It may also be worth mentioning that all attendees received a complimentary of Steve Denning’s book “The Leaders Guide to Radical Management”, which was previously on my wish list.

Day 2 – Session 2 : Don’t Start With Kanban!

Speaker : Marcin Czenko and Josef Bacher

Don't Start With KanBan

Don't Start With KanBan

With quite a controversial title I thought this would be an interesting session to attend. Often when you have sessions with controversial headlines such as these, they can be quite informative as they tackle problems with strong arguments and fact. Having previously attended a session “Using Kanban to Prepare a Scrum Project”, this could have provided a counter balance.

The presentation was well introduced and we were quickly split into teams with the task of making paper aeroplanes. Regardless of your age or background, making paper aeroplanes is always fun. The exercise clearly demonstrated some of the problems with Kanban being applied from direct waterfall environments and most people enjoyed it.

After the exercise was complete, unlike some of the other sessions there was quite controversial and to some degree heated debates. I personally think some information was lost in translation as some people were arguing the same points. The message which I think was trying to be stated was that Kanban applied incorrectly can counter some of the benefits of Agile. In some cases it could be used as a mini waterfall and miss the Agile benefits completely, whilst on the contrary when fitted on top of or with Scrum it could be mislead or misrepresented.Nonetheless the discussion was interesting and demonstrated some of the pitfalls when jumping into methodologies such as Kanban. It certainly wasn’t the smoothest session at the conference, but I enjoyed it all the same.

Day 2 – Session 3 : Using Scrum,Kanban and Open Space to Transform The World Of Instructional Design

Speaker : Jasmina Nikolic @jazilla

My experience with Instructional Design was limited so I thought this session was going to provide me with a good overview. This was a difficult session to choose as there were so many other interesting topics going on at the same time. With that being the case only about half a dozen people turned up, but this meant on the upside we had a very engaging and intimate session.

Although I didn’t really gain much knowledge on Instructional Design, the success story of applying Agile by Jasmina was a very enlightening. The challenge that she faced and the accomplishments made using Agile through leading academic institutions across the EU amazed me to say the least. It was also interesting to hear what was used, what worked and what didn’t work as well as some of the tools in place. This was very much an Agile war story with a light at the end of the tunnel. Not only was it interesting to see the actual working Kanban boards, on leankitkanban.com but it was exciting to see how Open Space become part of and integral to what I would call product design. Considering the barriers in place, the size of the task and other limitations, this was quite a story and I was glad to have heard it so passionately from the person on the front line.

Day 2 – Session 4 : Kaizen or Kaikaku – two approaches to improvement

Speaker : Arne Ahlander @ArneAhl

Kaizen

Kaizen, Kaikaku & Hansei

Continuous improvement is an expectation and at the same time a challenge for organisations and teams. Often in Lean environments Kaizen and Kaikaku are heard. I wanted to attend this session to find out more about these methods of change.

On entering the room Arne made a point of introducing himself personally to those in the session which was a great way to settle everyone. He then went onto a very well presented slide show with interactive discussions on Kaizen, Kaikaku and Hansei. Originating from Japanese cultures these were well described. For instance the emphasis on Hansei one should regret mistakes and promise not to make the mistake again.

Being an interactive session, lots of other elements emerged such as “Double Loop Learning” as well as some of the ways and approaches companies should and shouldn’t manage change. We discussed and were presented with the need to value making mistakes in order to learn and build as well as other facets such as why diversity is essential.

Following this Arne got us moving around the room and introduced us to some very motivating and thought provoking games demonstrating some of the issues discussed. I thoroughly enjoyed this session and was pleased I chose it.

Day 1 >>

Day 1 Scrum Gathering London

Posted by Craig Strong | Posted in Scrum / Agile, Software Development | Posted on 17-10-2011

0

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 @bobsarniBigVisible.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 >>

Giving Power To The People Who Make The Changes

Posted by Craig Strong | Posted in Miscellaneous | Posted on 04-10-2011

0

I recently wrote an article “Power To The People” for Agilescout.com. Businesses miss out on so much productivity value when people are not empowered enough to carry out their tasks. By giving people responsibility, direction and room to innovate against business requirements, innovative solutions and increased production values can be obtained. Have a read and see what you think.

Planning by value alters the routes of projects

Posted by Craig Strong | Posted in Development Practices, Product Backlog, Product Management, Product Owners, Scrum / Agile, Software Development | Posted on 17-08-2011

0

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.

Link with AgileScout.com

Posted by Craig Strong | Posted in Scrum / Agile | Posted on 27-07-2011

0

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.

A Programmers Reading List

Posted by Craig Strong | Posted in Books, Miscellaneous, Software Development, Software Reviews, Useful Links | Posted on 15-07-2011

4

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


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

Patterns of Enterprise Application Architecture 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

Code Complete: A Practical Handbook of Software Construction 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

The Mythical Man Month and Other Essays on Software Engineering 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

The Pragmatic Programmer 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

Clean Code: A Handbook of Agile Software Craftsmanship 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

Head First Design Patterns 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

Domain-driven Design: Tackling Complexity in the Heart of Software 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

http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/ref=sr_1_1?s=books&ie=UTF8&qid=1310818651&sr=1-1 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

Refactoring: Improving the Design of Existing Code 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.

Managing Contingency Within Scrum Projects

Posted by Craig Strong | Posted in Contingency, Deadlines, Development Practices, Product Backlog, Product Development, Product Management, Product Owners, Project Management, Scrum / Agile, Software Development | Posted on 06-06-2011

0

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.

Quality Is A Path To Agility – (FrAgile)

Posted by Craig Strong | Posted in Business, Development Practices, Product Backlog, Product Development, Product Management, Production Environments, Scrum / Agile | Posted on 07-05-2011

Tags: , , , , , , , , , , ,

0

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.

A simplified look into cross-functional team structures

Posted by Craig Strong | Posted in Business, Development Practices, Product Centric, Product Development, Production Environments, Risk | Posted on 28-03-2011

Tags: , , , , , , ,

0

It surprises me how many people don’t fully appreciate what cross-functional teams (CFT) are or what they aim to achieve.This ends up creating problems, increasing costs, lowering moral and hindering progress. However outside the business environment many people fundamentally know the principles of a CFT, particularly anyone who has an interest in sport. The same people are sometimes incredibly passionate team players and go over and above to help their local soccer team achieve, even if this means playing in different positions just like the generalised specialists of Agile. However in a working environment, working with others outside their department is a chore and often avoided by some. Therefore why is it difficult to solve the same problem in business environments. Before we look into more details of CFT’s lets look at an official definition of what a CFT is :

“A cross-functional team is a group of people with different functional expertise working toward a common goal. It may include people from finance, marketing, operations, and human resources departments. Typically, it includes employees from all levels of an organisation. Members may also come from outside an organisation (in particular, from suppliers, key customers, or consultants).” – http://en.wikipedia.org/wiki/Cross-functional_team

If you were to slightly reword the definition above, you would end up with a close definition of what a soccer team might be :

“A soccer team is a group of people with different skills working toward a common goal. It may include players in attack, creativity, defence and man management. Typically, it includes players from all levels of physical and mental ability. Peripheral members may also come from outside the team (in particular, physios, trainers, fans, or sponsors).”

Although that is a pretty limited comparison, its pretty obvious to see that they are both basic examples of a team. As simple as this sounds, in business the idea of a Cross-Functional team is complex and for some people unachievable and/or undesired.

Good Team Work = Good Results

When creating a simple product no one skill is above all others. It requires team work, collaboration and good communication. If you look at any product that inspires you, I am pretty confident it impresses you because the people behind the product worked well together. You only have to look at an iPhone to see that the designers, developers, engineers, marketing, sales and other areas of the business worked together to create a single product.
Creating cross-functional teams increase the potency of a product in the market place. Staying with the soccer analogy you can see the power of teams in almost every competition. If anyone remembers Greece won the UEFA Euro 2004, not by having the most expensive players, or the worlds best striker, but by having the mentality of a team and a desire to win as a team :
“The Greeks, dismissed as rank outsiders before the tournament with bookmakers giving odds of between 80–1 to 150–1 for them to win, defeated some of the favourites in the competition including defending champions France and hosts Portugal, who Greece beat in both the opening game of the tournament and the second in the final.” – http://en.wikipedia.org/wiki/Greece_national_football_team

Functional Units vs Cross-Functional Teams

One of the main arguments and a valid one which prevent cross-functional teams existing is the benefit of functional units. A functional unit is a group of people grouped by a similar function for example developers with developers, designers with designers etc. The benefits of which mean that as a professional unit, strengths and processes can develop well and they can communicate with strength and confidence on how to develop further. I have no doubt that grouping people by skill will have it’s advantages. The problem is that one skill doesn’t make a product.

The sweet spot of team structure is to have the teams arranged by a purpose (product), but to have the communication of functional units.To solve this problem you need to ensure communication is managed well and is very strong. That means that efforts have to be made in order for this to work. Again referring to the soccer analogy this happens quite nicely. Although you have goalkeepers and strikers in the same team, they don’t undertake exactly the same training all the time and come together at set times with purpose. Therefore strikers will train with strikers and develop the skills needed to be a striker, but play with all the other positions for the match.

In business it’s not easy to split people up like the training example above. People have computers, desks, commutes etc. Therefore how can this be achieved ? Well one thing we have tried in work with some success is to have scheduled “Round Table” meetings. These are set times where all developers, testers or designers from different projects meet and discuss their problems, achievements or proposals. This seems to have had a positive affect and are time boxed so they don’t interfere with production metrics. There are many other methods which could help achieve the above such as weekly, fortnightly meetings (limited time); where each team can tell other teams what it developed and what it plans to develop in and how (like a large scrum meeting), good documentation, set training etc. The point is communication processes and time need to be recognised and set up just as you would schedule training in a soccer team. Unless an effort is made to account for the problems with cross-functional structures, the negatives will be problematic and a successful team will not materialise.

Fielding A Cross-Functional Team

If I was a soccer coach and was dealt with the task of fielding a team for the next match how do you think the following tactic would prevail for 90 minutes :

Isolated Functional Units

Isolated Functional Units

Looking at the “Attacking Tactic”,I’m pretty confident although my team might score some goals, but the opposition would score more. Looking at the “Defensive Tactic”, I’m pretty confident that I can limit the amount of goals conceded, but my team probably won’t score many in the process. With both examples, I am also pretty confident the players, coach, directors and the fans would be a little concerned with my approach and probably question my capability as the teams manager. It’s pretty obvious the team in both examples is off balance and doesn’t contain structure, limiting the chances of success. However obvious in both these examples, businesses often adopt these structures. They have teams which consist of isolated skills and capabilities and then shut them off to the other skill sets, forcing them to work in isolation physically and discourage communication.

If I was however to field a team for match day which combined all the skill sets which had a balance between defence and attack, with everyone working with a common structure and goal, I would increase the teams chances of success. To put this in perspective, match day would be developing a product in the business sense. The following very simple example demonstrates a teams structure from a business point of view :

CFT Soccer Zones

Hopefully the example above clearly demonstrates why and where different skills are needed. (I know it’s very simplified).

If its that simple, why doesn’t everybody do it ?

The analogy in this post over-simplifies a sometimes very complex business structure. For instance football team is 11 players, where as a business can be thousands. That being said, the basic strategy is relative.

There are countless reasons why this doesn’t get implemented in many companies, some more valid than others. However in my opinion some of the most common reasons why this is difficult to implement include communication, responsibility, ignoranceconfidence and trust. Let me explain :

Communication

Businesses are often structured by departments, not by products. Naturally the environment is restrictive which will reduce communication and if your are co-located or international you need to allocate time and buy tools to invest in communication strategies. Being structured this way also hiders incentive. Why should Sales communicate with QA for instance? They don’t need to, “we work over here, they work over there and we do different things”. Working in isolation reduces the visibility of the big picture which is that everyone is on the same team. Instead there is more loyalty and effort shown to the each of their own departments. Waterfall project models emphasise this in their structure, when phase 1 is finished move it to another department for phase 2 and so on. This approach is fine, but often as a project moves through the sections, the vision can be lost. In a lot of cases as the project moves on through the departments, the motivation, incentive and understanding can diminish as well, causing the business to be less responsive.

Responsibility

With skills/departments not communicating well with each other, responsibility and ownership sits comfortably within the departments. If engineering make a mistake, it’s not the responsibility of marketing right? When you group people by profession and isolate the skill sets coupled with poor communication of course, a blame culture is encouraged which furthers the separation between functional units. Unless there is a common responsibility between the functional units to communicate, they will drift further apart hindering the benefits of working as a team and therefore affect the product. Organisations who don’t encourage functional units to take responsibility help further the divide at their peril. However most organisations don’t identify, encourage or monitor this responsibility as such. Yes you do have project managers who work with many departments, however project managers can work with functional units in isolation which is no benefit in getting functional units working towards the big picture. In a soccer team, you have a captain, coach and manager all making sure the team is communicating, in business you don’t always have these people.

Ignorance

If your skills and interest are limited to your department, domain or comfort zone and you are doing what is asked, why bother helping or bother spending time working with others not related to your craft? Do people from IT really need to care what Marketing do or vice versa? Of course the answer is yes to the previous question. Ignorance is more than often a choice by an individual. It’s very easy to do other people’s jobs everyone will have you think. Breaking down the barrier of ignorance can have huge benefits not just for others, but also for yourself. If one understands how others work they might structure their work differently which could increase overall performance and efficiency. Taking the IT/Marketing differences as an example, for IT to receive a change request through from marketing to a preview environment it might benefit marketing to know that each chance to a static page of content takes 3 hours of testing and 2 hours of deployment for instance. Knowing this might ensure marketing provide copy in a better state before passing it to IT, which in affect could change 10+ hours into 5 hours making the company more efficient by saving time and money. I have no doubt that Ignorance like this is costing companies millions of pounds per day!

Confidence And Trust

Yes believe it or not this can play a big part in poor communication in business. Functional Units often have leaders. Some leaders like to lead and like to be seen leading. Where functional units isolate persons and teams away from the big picture which is the cross-functional team working towards the same goal, leaders with inflated ego’s will not want to communicate. If you think you are doing a great job you might not want to give other leaders from other departments any insight to how you work as it will expose your processes which may involve weaknesses as well as strengths. If a player a soccer pitch holds onto the ball all the time and doesn’t pass, you pull them onto the bench quickly even if they are very good individually. In business who does this and is it as easy to spot?

So Now What ?

Well this post explains a simple analogy of cross-functional team structures. Obviously businesses are complex, but the same approach can be applied. For cross-functional team structures to work, decisions need to come from the top and effort need to be made to encourage the structures/tactics to have a chance to work. Analysing operations and refining processes will go a long way on setting up cross-functional teams, but just like soccer teams, they need management, structure and direction. Unless the vision is shared, the functional units have motivation,ability to communicate and people see themselves as team members and not the team, it will be difficult if not impossible to implement. Creating cross-functional team structures is a culture change as much as it is a structural change. Such changes take time, effort and planning which deter most who don’t wish to undertake long term thinking. However implemented well just like Greece winning the European Championships, you can generate more output with less input and increase your chances of success. Not all companies can be structured like this, but I’m sure the one’s who do will not look back in most cases.

If you have any feedback on this post or your company structures and experiences, please send me your response.