The PMI Announcement
As a result of the news that the PMI have endorsed Agile Project Management I was doing some reading around the topic and came across this article. The question posed seems like a very traditional project management question because it is asked from the basis that everything is delivered at the end of a project. It doesn’t consider that a scope could be wrong, or the times are impossible or the costs are not enough. This is what project managers are taught and this is one of the reasons that so many projects fail, in my opinion. To be able to predict an arbitrary date sometime into the future that is months, years or decades away is a nonsense. Predicting how much money you might spend or what the scope might be during that period seems even more impossible to my mind. And when you finally throw in poorly managed engineering techniques which diminishes the quality, you are always left at the end increasing time, budgets and reducing the scope. Without having built up any knowledge as to whether your predictions might be accurate or not people are committing to the parameters of time, cost and scope (quality is always high at the beginning of any project when it is just a thought in someone’s head, but diminishes when the reality of building stuff actually kicks in which is why the commitment of any project doesn’t really consider quality).
I know this is quite a glum scenario, but there you are. It is still the most common scenario that I see in environments where projects are the norm and commitments are made to be concrete on the back of an approved project. I think the fact that the project is really the only construct discussed by the project management community is what creates this thinking – the clue is in the title! I remember saying to a client a couple of years back ‘I guarantee 100% that you will NOT get 100% of the things you are thinking of right now on the date in your project plan that is over 18 months away. But, how about we work with a little more uncertainty and we aim to deliver 60% to 70% between this date and this date approximately 18 months away so that we can get something into the field for a real trial with real customers, and we would have already got feedback on what we have been doing at regular intervals beforehand. Which one would you prefer?’ The debate that this created was interesting, because people started to say: ‘well, it would be good to get something to play with before the end date and something we could show our customers’. Others were still very much: ‘well, we have to deliver everything on the date’. So, I simply asked: ‘what is everything?’. Stunned silence followed.
I know many of you will have been in similar surreal conversations in your work too, but it always strikes me as a little… well, stupid. The proliferation of the idea that complicated projects can be predicted so accurately is absurd. The XP game has demonstrated many times to many teams that even the simplest tasks (like blowing up balloons) cannot be predicted accurately until we have a few goes at it. If we try the same project over and over again, I guarantee we will get good at that project.
You get what you think about
I have come across this saying a number of times: Watch your thoughts for they become your words. Watch your words for they become your actions. Watch your actions for they become your habits. Watch your habits for they become your character. See your character become your destiny. I don’t know who this should be attributed to, but I do like it. In this context, it brings to my mind the fact that the focus of the project management community is focusing on the wrong things.
I remember when I got my first real budget responsibility as an IT Director. It was a very significant sum of money and one of my more mature and long-serving colleagues took me aside and said: ‘Phil, always hit your numbers. Never underspend or overspend your budgets. This is the most important aspect of your job. Hit your numbers and you will be fine.’ The young, idealistic me was a little taken aback by this advice. I thought the point was to deliver the projects and programmes, but apparently I was mistaken. How naive.
For me, the focus on trading time, cost and scope off against one another is the wrong focus. I think managers should be focusing on Value, Flow and Quality. Each of these words require many more posts to do them justice, but my intention here is to say that the project managers (or any managers involved in delivering products, services, systems, projects, programmes etc) should focus on creating these three things in their organisations. I am not arguing that cost control is unimportant. It is important. But, it is ridiculous to believe that this is the most important thing. The biggest ‘cost’ of a business is a failure to turn ideas into valuable products and services that meet or exceed the expectations of customers. Going further, there is an implicit cost of not delivering quickly. For every extra day a feature takes to be delivered a day has been lost reaping economic benefit for that feature. This is the Cost of Delay and managers need to understand this.
Value is not fluffy
One argument I have heard on numerous occasions is that it is difficult to really understand the value of an individual feature or activity, and that’s why we focus on cost. We know how to deal with costs. Value is difficult to measure. This makes no sense to me. If it does to anyone who reads this, please try to enlighten me. I do want to learn.
In the agile community the word value is used a lot. In fact, in my experience it is overused and abused to argue for the things that people want to do rather than things that have real value (i.e. money/economic benefit). I hear the cries now: ‘What about other value types such as happiness of employees?’. Happy people has an economic benefit. Heskett et al postulated a model called the Service Profit Chain that links employees, customers and quality into a profit model. The challenge is creating a value model that works for your business that allows you to trade off different features, requirements and improvements in what you intend to deliver and the way you intend to deliver them. Please remember that any model you create can be refined as you learn more about how that model is being used. You might not get it right first time, but you can definitely have a good debate with your finance director about how you trade things off for the highest economic return.
Projects are short-sighted
One of the problems with projects is that they are inherently short-sighted. A project manager is judged on their ability to deliver the project, however they do that. It doesn’t matter what state they leave any underlying IT systems, product architectures or people who were working on the project. Managing the assets of a business with a view for the longer-term is a philosophy that is promoted in lean, and is an important principle to be instilled in managers and should be considered when designing any organisational structures and philosophies. When I see organisations that are set up solely around projects and not the underlying components and systems I get nervous. If more than one project manager affects a common platform without any need to care about the quality they leave behind and the ability for the next project manager to be successful then there is an issue. Projects do not promote flow. They should be used more sparingly than they are.
Quality is not negotiable
One of the strongest statements that has come out of the agile community is that Quality is not negotiable. As I mentioned in a previous post you need to demand technical excellence. However, as I mentioned previously, when people think about quality at the inception of a project it is easy to think that your project is going to be of the highest quality, but reality bites when you get going. It is easy to have standards about your engineering when you are in the throws of thrashing out your requirements and design in a traditional project. But, why do we believe spending our time on requirements and design at the beginning of a project is more valuable and important than spending time of creating the right environment for building high quality software? Quality and productivity are inextricably linked. Poor quality now will slow you down in the future. Great quality now will increase the flow of value and improve speed-to-market over the longer-term.
A virtuous circle
Time, cost and scope are often called the Iron Triangle. It sounds like a very negative phrase. I prefer to think about something that creates a virtuous cycle. Value, Flow and Quality creates a virtuous circle. This does not mean you are challenging the laws of physics as the article mentioned at the beginning suggested, but it does change the mindset about how you can manage your product, service and IT deliveries. The idea is to go as fast as you can possibly go. Managing projects to time, cost and quality hasn’t given us the ability to go as fast as we can go. If the PMI’s announcement starts to educate project managers to start thinking this way, then I believe it is a really valuable move for our industry. Time for a change? I think so.
Thinking about networks
My formative years in technology and delivery were spent in the telecoms industry. I have learned a lot about how networks work, how they are controlled, managed and planned, and the strategies involved to deliver certain qualities of service to customers. In fact, at one point in my career I was responsible for designing and delivering all of the systems that planned, designed and stored most of the network assets and services within BT. I spend most of my time now considering how enterprises deliver value through projects, programmes, products and services and I find there are many overlaps between the two worlds. I have been re-reading Don Reinertsen’s ‘The Principles of Product Development Flow‘ recently and it brought me back again how telecoms theory can influence the delivery of value in an enterprise.
A past experience
The last major programme I worked on in BT before leaving was designed to introduce a 24MB broadband service to large parts of the UK. There were many firsts in technology underpinning this programme in creating a ubiquitous IP core network and how that would be planned, managed and controlled, but the key element that would enable the faster (and I know other technologies are faster, but not as available) speed to customers was based on a technology called DSL Max which had previously been used in the rollout of 8MB broadband. This technology was designed to enable any copper line carrying broadband to an end customer’s house to be as quick as it can physically be.
DSL Max is an example of a ‘Rate-adaptive service’. Wikipedia describes it as ‘… intended to offer the best possible speed attainable, which may vary over time. The maximum speed permitted is determined both by current line conditions and the level of noise, and also by recent history based on factors including the rate of communications errors and the best and worst DSL modem sync speeds achieved during some recent period of time …Customers with long lines or poor quality lines or who experience high levels of noise or interference will be limited to much slower transfer rates, and some customers whose lines are very poor or who are affected by high levels of noise may be unable to obtain service at all.Interestingly, this technology has created a little bit of contention in the marketplace because customers like to know the exact speed that they are likely to get from their broadband provider, but this technology says (at least in the copper network) that you will receive the fastest possible speed. It reminds me of the need from enterprises to know exactly how each team compare to one another and how fast they will go in the next 6 months – it kind of misses the point!
The technology does not necessarily dictate the ultimate end-to-end service speed because of the different aspects of how the core network and internet operate, but it has a major influence as to what the end-to-end speed can be. The interesting points, for me, from the excerpt above is the there are a number of factors that can influence speed – the end points or Interfaces (DSL Modems), Distance (from the Controlling elements), Noise and Interference – and it may vary over time. In some ways the things that impact network speed are similar to those that can impact speed-to-market for companies.
What does this mean for teams?
The team is an interesting construct because different people look at different parts of groups as teams. Agile folks generally consider a team to be a small (7 +/- 2) cross-functional unit of people delivering valuable features. But for something like the programme delivering 24MB across the UK, the ‘team’ spanned hundreds (and maybe) thousands of people. I was part of an IT leadership team tasked to deliver the overall programme that needed to operate as a team, and I also had around 300 people who were part of teams actually building features internal to my department and across other departments through integrated systems and technology. In this sort of environment it is very difficult to define what a team should look like or how small value units might operate within this context to a shared goal for the organisation. That is where project management has a role to play.
In Management 3.0, Jurgen Appelo covers structures and teams really well, and discusses the principles about the size of teams, the structure of teams and their interactions. I liked his approach to the topic, because I have always found the rhetoric from the Agile community a little disconcerting and not too achievable in the context of massive programmes of work. One of his points is the idea that the project managers role is to manage a project and not the people, which is counter to how most project managers and organisations behave. For us though, it really made sense and that was the approach we had taken within the programme – we created networks of teams that came together to deliver value for the customer and disbanded to work with other teams. That is to say, we allowed the teams doing the real work of developing solutions to be small enough so that they could self-organise around their own technologies, domains and features, but created some more ‘functional’ teams to act as nodes of understanding, communication and alignment between teams. Our goal was to align all the different teams up-and-down the programme in order to deliver incremental business scenarios. To start off with, we needed to give it a little nudge in the right direction as self-organisation wasn’t going to work across the different suppliers, organisational units and technologies.
My job as a manager was to help make all of my team units as effective and valuable as they could be across the wider programme. In short, my focus was to manage and deal with the Interfaces, Distance, Noise and Interference impacting my teams so I could enable them to go as fast as we could go.As a side note, this was for the good of the overall programme: the area I had inherited to ‘fix’ were already identified as the bottleneck for the overall delivery and a certain pressure came with that ‘gift’.
The definition of noise is: it can block, distort, change or interfere with the meaning of a message in human, animal and electronic communication.
I think anyone who has worked in any organisation can recognise noise. The world is full of things that can distract you from the task at hand. One of the roles of a manager is to limit unhelpful noise. There have been many times in organisations I have worked in that I have witnessed people creating noise for the sake of wanting to be heard. Throwing rocks from the sidelines. Passing judgement on the work of others. Often, this noise is like ‘anti-value’ for a team. Noise can come from many directions when delivering complicated, integrated technology solutions for complex businesses. It can come from the technology itself (especially if the technology chosen is new to a team – or just new). It can come from centralised groups who are not focused on the flow of value and are part of ‘economy of scale’ thinking. It can come from people who don’t really understand what a team is doing. It can come from project managers who feel that they need to control activities because ‘that’s their job’. It can come from people who are detailing the requirements if they don’t understand their own business. In short, as a manager, you need to have eyes in the back of your head, but more importantly you have to be available to reduce the noise affecting a team. Being there to breakdown organisational roadblocks and issues is an extremely valuable role when done well.
Interference is anything which alters, modifies, or disrupts a signal as it travels along a channel between a source and a receiver. The term typically refers to the addition of unwanted signals to a useful signal.
Similar to noise, Interference can come from many angles in an organisation. In telecoms their are a couple of common Interference types such as Cross Talk and Adjacent Channel Interference that can have a major impact on the performance of a circuit. The weather can sometimes make things worse too. I think there are a couple of common interference personas in organisations:
- The Bulldozer – a more senior person who wants to come in and set direction. Someone who generally bullies a team into doing what they want them to do without understand the full context.
- The Know-It-All – someone who solves the problems for the teams. This person can take away any accountability and responsibility for a team and leave them headless when they are not around. They can all set direction that often tries to solve the future and complicates the immediate task.
- The Seagull – we have all had senior managers and advisors who take a peek at a situation, swoops in, makes some snap decisions and swoops out again. They don’t take the time to understand what is really going on and help the team. Seagulls can sometimes be Know-it-alls.
- The Jobsworth – the homework checker who doesn’t like what they are seeing and have other goals to deliver that are not necessarily in support of the project being delivered. I do have some sympathy for this role as everyone has their job to be done… it would just be nice for people to be able to apply some judgement to a situation. These may well be the people who would want to compare one team against another.
- The Person-who-has-something-to-prove – people act from their own perspectives, and people’s goals don’t always align to the goals of the team. This might be someone who wants to make a name for themselves, or someone who wants to exert their authority in a political situation. Whatever the reason, this is something to be aware of.
- The Spare-Wheel – someone who doesn’t really know what their role is in the team. They might have once been a manager of a team in an older organisational context that now doesn’t really know how to add value. Changing organisations can often create Spare Wheels, so beware.
I’m sure there are many other personas we could name. I would be happy to hear some of yours. The key thing for managers and leaders are to keep an eye out for interfering behaviours. Advice is all well and good, if it does genuinely support the goals and needs of a team, but this does need to be managed carefully.
In the context of the programme, the distance I am talking about is that between the teams day-to-day work with their heads down working alongside their own product/domain specialists and that of the end-to-end business and Integration points. In one respect distance issue is the same in both telecoms and enterprises – the further away you are (in space and time) the more the communication degrades. It is often easy to become fixated with ‘getting your bit done’ in a large programme like this, but it is only as an end-to-end team would we be successful. A lot of my job as a manager was about making connections between the different teams and stepping into situations where misalignment was occurring without any of the teams being aware that this was happening. In large, complex organisations you cannot hope to know the full complexity of the political landscape and the intimate detail of the working software. You must have bridges and connectors to get the right people talking at the right time.
In the metaphor of the copper line telephony service, the Interface is a Modem or other Network Node. These are the senders and receivers of information. In an agile team, this might be a Product Owner or another team that you need to interface your software with. It might be someone within the business who will use your system. It might be some other interaction. Whatever it is, interfaces have a real ability to impact overall velocity of a team. This is an area where the wider ‘team’ in a programme sense needs to spend time to discuss how interactions will take place and how alignment will happen to keep the overall system moving forward as quickly and effectively as it can. Often, interfaces span organisational boundaries, technical boundaries or priorities and managers need to be aware how these can impact the teams. Teams can start to self-organise once interfaces are understood and relationships are built. Often the role of a manger with the wider organisational context is to grease the wheels of an organisation and make the connections to start with. It can all flow from there.
Wrapping it all up
Ultimately, as a manager of an organisation, you want your teams to go as fast as they possible can go and that the organisation, as a result, goes as fast as it can go (we don’t want fast teams if the whole slows down!), and in order to do that, special attention needs to be given to the things that can hamper a team’s performance. Noise, Interference and Distance are not things that you can do too much about in a simple copper network (there are some things you can do to help, but, only so much), but they are all areas that can be managed and looked at in complex organisational environments. A lot of these elements are often overlooked by managers and in some cases it is the manager takes on the personas described. Forearmed is forewarned. The success of your programme may depend on it.
A few weeks ago I was facilitating a session with a group of people responsible for delivering a software platform to support a number of very large institutions in complex markets. The session was centred around how you could create more collaboration, predictability, communication and feedback into their delivery cycle and how the different groups and roles might better interact with each other to deliver higher quality, valuable software and solutions to their customers. They have had problems meeting their commitments to-date and when they have delivered it hasn’t really met their customers’ requirements. A common problem that we’ve all heard about many times now.
Their normal approach is full of hand-offs, long lead times between specifying something and seeing it in reality to provide real feedback, and very document rich to support people’s ailing memories across these long lead times. During this session there was a real feeling of parochialism. The Development Manager was arguing the QA needed to step up to do such and such. The QA Manager was saying the Dev were always delivering sub-standard work. Everyone was pointing at the requirements still being worked on. And the designers and architects had such grand plans that weren’t achievable. It was the classic example of the silo organisation. The interesting thing is that all of their backs are against the wall because they have deliveries to hit. My point to them was: QA fails, you ALL fail. Dev fails, you ALL fail. Design fails, you ALL fail. There was silence in the room and then the penny dropped. They realised that they should be a team.
I read two blog posts yesterday that made me think about this situation. The first was the TradableQualityHypothesis by Martin Fowler. The second was Mike Gaultieri’s ‘Want Better Quality? Fire Your QA Team‘. Both posts were ultimately about the ownership, accountability and responsibility of quality. For some organisations they believe that quality is improved by spending more time on getting the requirements right. For others it is about getting the design right. For a lot it is about spending all the time on QA. Not many firms actually believe (in my experience) that the developers are really the ones who can help because it has become for large enterprises a commodity – which is completely wrong. However, for the teams and organisations who actually produce high quality work they understand it is about everyone systemically collaborating and working together to develop solutions. Everyone is responsible for quality. Interestingly, in Mike’s article, the extreme position of firing the ‘Quality’ team had the amazing effect of everyone else taking accountability and responsibility for the quality of the output. It would be interesting to understand what actually happened and if it supported the hypothesis of Tradable Quality too. My guess is that the Internal Quality was increased significantly as a result.
I’m not necessarily espousing that all teams need to fire their QA departments, but I am very much of the mind that all of the roles and responsibilities need to be blended into a one-team mentality whereby everyone succeeds or fails on each others’ quality and performance. The key thing for me is that Managers and Directors need to understand that they will damage their future business unless they really understand this. As I said in my last post, Demand Technical Excellence, or you will all have a case of high dynamic complexity and lots of finger waving when the IT platforms grind to a halt.
In his book Solving Tough Problems, Adam Kahane describes 3 types of complexity: dynamic, generative, and social. Dynamic complexity describes the time and distance between when a cause is in introduced within a system and when the effect is stumbled across. The closer the time and space of cause and effect the lower the dynamic complexity. Generative complexity is the subject of how well known a problem is and how many time that problem has been solved. In other words how predictable and familiar a problem is. The final complexity type, social complexity, is about how aligned people and groups are in terms of assumptions, beliefs, values and objectives. A well-functioning would ordinarily have low social complexity because people understand the values and objectives of the groups and take the time to share assumptions.
In emergn our jobs allow us to work with teams, projects, programmes and business units who are all looking to solve complex organisational issues that contribute to delivering products and services. The techniques we deploy from the agile and lean philosophies are geared towards lowering these three areas of complexity.
IT is Business
My main interaction within enterprises are with IT Directors, CIOs, leaders of business change and other Product/Service Directors who have responsibility of delivering new or improved products and services to their customers. One of the similarities of all our clients is that their businesses are highly reliant on IT deliveries and the quality of the software that forms the fabric of their operations. In fact, most modern organisations are now so reliant on IT that any IT transformations are really business transformations. This is quite a problem for a lot of businesses because a lot of people still see them as separate. The old thinking of ‘we need to outsource software engineering/IT as it’s not a core part of our business’ needs to be re-looked at or, at the least, needs to be understood better so it can be managed better.
10 Years of Agile
I have been visiting a number of our clients over the year who are undergoing major transformations in their IT systems to better support their business need for increasing speed-to-market, lowering the total cost of ownership and creating better customer experiences. This is a very common set of objectives and most companies are turning to agile and lean for solutions. Over the last weekend, 33 people from the world of agile got together to celebrate the last 10 years since the agile manifesto was introduced and to discuss the next phase of evolution. The first area that has been mentioned in every write up of the event is ‘Demand Technical Excellence’. In my role prior to emergn I was responsible for tens of millions of pounds of software and I recognise this point to be so important. I am often astounded (and dismayed) by the lack of interest by my peers in the need for excellent software craftsmanship and standards. Even more discouraging is the belief that this problem can be outsourced to a company whose fulltime occupation is to deliver software yet fail to show the levels of quality you would expect. This belief is often a bout of wishful thinking and sometimes comes with the belief that the harder someone stamps their foot and demands quality the more likely they are to get it. My view is that if you want quicker speed-to-market, lower cost-of-ownership and better customer experiences then you’d better invest in quality. Focusing on lowering the cost and speed of change of your software platforms will have a huge economic benefit for a business and will allow your customers to participate alongside you to develop excellent features that they really, really want. For me, this renewed focus from the industry is an excellent outcome of the event.
My advice for enterprises is that they’d better hire people who really care about and understand software and their business, and know how to really manage and monitor the software being delivered and how it is delivered by outsourcing partners. Relying on wishful thinking and contracts that ‘protect’ them will not be enough to remain at the top of increasingly competitive environments. This is a case of high dynamic complexity. Poor software engineering has massive implications to a company yet the effects of the cause are noticed years later and for years to come and across many areas of an organisation. This means the problem is not a simple one to solve, but one that will have a material benefit for a long time to come.
Companies that have moved forward with agile and lean transformations including rolling out Scrum, Kanban and other people/process oriented changes are making good strides forward which shouldn’t be ignored. However, without the investment in the quality of software and improving the technical excellence competency, the transformation can only go so far and any investments in whizzy new strategic architectures will probably end up in the same place.
A problem with labels
I find language fascinating. In fact, it is more understanding and contradictions of words that fascinates me. The same word said to two different people can conjure up wildly different opinions, thoughts, reactions and feelings. This is an example of the map and territory relationship or the philosophy of perception. Perception is reality to the person who perceives. This is why nouns and labels within the world are useful and, potentially, dangerous and confusing. Good marketeers use labels to attach good reactions and feelings to their products and services which draw people into in to spending their hard-earned money. However, in my world I come across confusion to labels every day because the label has become a bucket for concepts. An example that everyone can relate to is the word Gentleman. This word is commonly used today to denote a man who is inherently good – ‘He is a fine Gentleman’ or ‘He’s a Gentleman and a Scholar’. However, the meaning of the label in the UK was originally to describe someone of noble birth who was entitled to a coat of arms. The meaning has been blurred from a noun to more of a describing word (although it is a noun) meaning good, courteous or chivalrous.
The crux of the matter for project delivery
In the world of software development there are a couple of words that spark and generate numerous debates. These are the words Agile, Lean and Waterfall. I always find the debates fascinating because I like to understand what meaning has been attached to the label by the debater. The word waterfall has been used for decades to describe an overall project process that is phased from analysis all the way through to deployment of software. Such a delivery has been categorised as one with a long process, laden with hand-offs, and lack of feedback and learning cycles. In practice it is often seen as a method that tries to nail all the requirements upfront and then to all the design before actually building any software. But, I have seen other processes that build right from the start in parallel to other activities. I have seen variants with good learning and feedback loops. So, to use a label like Waterfall really conjures up people’s previous experiences in working on projects that could have taken a long time. This is really a massive generalisation and doesn’t necessarily speak to the challenges of project delivery.
The same can be said for Agile and Lean. Again, these words conjure up elements of good behaviour to people who have been involved in projects that have an iterative heartbeat. These projects can be categorised as one with learning cycles that have been built into the system, and software is used to measure progress – to name a couple. However, I have seen iterative methods been used very successfully on projects that still only had one delivery into production that took year (because the market really dictated this launch approach).
Taking a more principled approach
With emergn we try to move past the label approach quite quickly. Instead, the approach that I try to take is to understand the systemic issues with the current project delivery approach. The question shouldn’t be about do we want to do Waterfall or Lean or Agile. The question should be – ‘what do we want to be as an organisation?’ Every company I walk into has laudable values papered up on their walls, in their media and collateral, and even on mugs and t-shirts, but when you actually look at the behaviours within projects it is always unclear how the actual day-to-day working matches to the values being displayed so ostentatiously. I would argue every organisation would want to be described as agile or lean. Not one of them would like to be a waterfall (whatever that is!). Agility comes from the organisation’s system of delivery. The people, processes and technology that are in place. Kent Beck first introduced the idea of a more principled approach to the delivery of software as part of XP. This very much fitted with the ideas of thinking tools and the principles of lean. Bringing the best bits from these different schools of thought helps us move past the debate of labels and onto solving problems in delivery organisations. I think it is time to move past the labels and more towards being able to describe what a company can do as a result of improving themselves. There is something said to setting a vision of how you want to operate and then working out how you live that vision.
Over the past few weeks I have visited a number of our clients to discuss how their Agile Enablements are progressing. For me, it has been a hugely enjoyable experience to see and hear of the transformations taking place and the energy and value that has been created. However, often it is not the response from the teams that is most telling of progress, rather the reaction of senior managers. The reason that I say this is that senior managers get more than they bargained for by embarking on their agile journey. The normal promise for any improvement in delivering software is Faster, Better and Cheaper, and most people have learned to live with improvement along one dimension against a trade-off along the others. However, after only spending from as little as a few weeks to a couple of months with a coach learning the basics of running an agile team the key difference that people notice is the energy and drive of the people involved. This is when the reaction of the senior managers brings a smile to my face. They claim that their teams seem to be having fun. Fun at work!? How can this be?
Every person seemed to have a renewed interest in the value that they are delivering for their business partners and customers. This is a repeating pattern that we find when we coach teams. It has to be more than the Hawthorne Effect.
Is having fun an acceptable practice at work?
It got me thinking about the work Lynda Gratton has done on Hot Spots. Her book is about how groups of people can come together to deliver amazing results. It’s a book that explores “Why some companies buzz with energy and innovation – and others don’t”. She starts the book by saying that you know when you’re in a hot spot.
“You feel energized and vibrantly alive. Your brain is buzzing with ideas and the people around you share your joy and excitement.”
This is what the senior managers were describing to me and I wanted to find out how the lessons and practices described in the book compare to and support agile.
Throughout the book the following equation is referred to:
Hot Spots = (Cooperative Mindset x Boundary Spanning x Igniting Purpose) x Productive Capacity
Bringing together and fostering cooperation that spans across and beyond organisational boundaries to work on a problem that supports a brighter vision of the future seems like a reasonable recipe for success, and the book explores a lot of examples and practices that support this. However, it was the final element of the equation, Productive Capacity, that really piqued my interest in regards to the comparison with agile. 5 practices were identified that described how teams could increase their productivity and support more complex Hot Spots:-
1. Appreciating Talents
2. Making Commitments
3. Resolving Conflicts
4. Synchronizing Time
5. Establishing a Rhythm
When I read on to understand these practices in a bit more detail I realised that these directly complement agile practices and principles.
Running an agile team (correctly!) directly supports the Productive Capacity practices required to create a Hot Spot. Agile brings together people across organisational boundaries who have often not interacted in any meaningful way before. This is the first step to appreciating other people’s talents. The basic agile framework describes a number of key ceremonies that:
- get everyone making commitments publicly and not having commitments thrust upon the team through Release Planning and Iteration Planning (One volunteer is worth ten pressed men);
- synchronize everyone’s times to ensure participation in all the key planning and feedback sessions such as Show and Tells, Retrospectives, Planning games and Stand Ups;
- and establishes a cadence for releasing solutions.
The final link between agile and the practices behind Productive Capacity is in resolving conflicts – this can sometimes be the hardest part. Running a project in an iterative way that is ‘planning driven’ and takes constant feedback will highlight problems (or opportunities) – daily. It is the job of the team to address these problems and remove blockers. Conflicts will arise and must be tackled. These problems have always existed – agile highlights them. The best teams that I have seen embrace the feedback and work together to resolve conflicts to continually improve. When you can combine these practices with agile’s non-negotiable approach to quality you get really amazing results.
There are many examples of Hot Spots in her book – some of them are IT related, but most of them are not. The Agile Values – communication, feedback, simplicity, courage and respect – supports a company’s ability to bring together high performing teams that create Hot Spots of innovation and performance. If you could really have Faster, Better and Cheaper being delivered by people who are energised, motivated and committed to achieving your goals, wouldn’t you do it this way? I know a number of organisations who believe the answer to this question is now a resounding ‘Yes’.