Practically Agile

As a coach it is very easy to get wrapped up in theory rather than practice, the topic itself is challenging because it is so simple to understand but so difficult to execute. We see so many Agile Transformations fail, so many poor implementations of Kanban or Scrum and at times it feels great other time so futile, the concepts are neither complex, nor new, but they are very difficult to implement effectively and in a lasting manner.

Successful Agile Software Development is in my opinion based on three similar but intertwining thought processes and if any one is absent the strength of the whole is significantly diminished.

  • Systems Thinking
  • Community Context
  • Reflective Practice and Application

Sometimes we get focused too heavily on the principles and the values but the Manifesto begins with what I think is a statement more important than the rest.

Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.

At the very heart the manifesto is about getting better at delivering software.

We are uncovering better ways” – it is a journey of discovery, we do not have all the answers.  “by doing it and by helping others do it” – It is not just theory, and we share our successes with others so they can benefit from our past successes and failures.

Systems Thinking

It sounds grand and perhaps I would be better served coming up with a less grandiose title but essentially the issue here is that YOU are not the center of the universe. You could mean you personally, or your team.

Systems Thinking = YOU are not the center of the universe

The goal is effective Agile Software Development, solving a problem for a user, with software.  Our system is the whole process from identifying a need, through to the delivery of a solution, and that solution being used to satisfy a need.

Our system is not coding; it is not moving a card from one column to the next.

Having great code on a branch that will not get to the user for months or years (if ever) is not satisfying customers, however proud you are of it. The same is true for designs or perfect architecture for features not needed .

Transformation failures

In my experience I would attribute a significant majority of unsuccessful transformations (and many business failures) as a result of a failure by members of the team to grasp that they are contributors to a larger system, it sounds insensitive, but you are just a link in a chain, a cog in the machine. Focusing too much on one small part is not helping the organisation or the system as a whole.

And yet we expend a lot of effort on improving local efficiency, and at the same time failing to grasp that your efficiency is irrelevant without context.  By focusing on your own local efficiency is at best doing nothing for the larger system and at worst making the larger system less efficient – by not focusing on what is needed.  The obsession with coding efficiency in particular kills a great many software products. I see teams actually proud of a growing pile of stories in need of testing, or a team dedicated to front end UI proud of having endless features complete against mocks and how the back end teams can’t keep up. Sadly these teams seem oblivious to the fact that they are not adding value to the system.

Community Context

Systems thinking refers to the context and the domain but within that is a team – often many teams. The teams are a collection of individuals – all distinct and all different, and your ability to work together (or not) can determine how well you are able to produce software. Teams that bond and grow together achieve amazing things, teams that fail to establish trust can and do churn without making much progress.

An understanding that software development is about people first and foremost, may sound an odd statement when media presents it as a lonely and socially awkward enterprise. But all aspects are about interactions, within the team, with users, with stakeholders, with other teams, the list goes on, but effective communication drives software development.

Those that master the understanding that product creation is a people centered activity and overwhelmingly a team activity will thrive, we build cross functional teams in the belief that self-organisation and motivated groups produce great software – and they do.

It can be tough adjusting from thinking about you as an individual to you as a member of a larger community, but when we can act in a way that best serves our community rather than ourselves we start to become a high performing team, it is worth noting that you do not create a high performing team by simply grouping a number of high performing individuals, often that is a disaster.  High performing teams arise when we learn that we are more that the sum of our parts.

The second part of this is that part of being in a community is sharing knowledge and offering support. The manifesto calls out that part of being agile is not just doing it but helping others do it.  We find ways to grow as individuals and together.

Reflective Practice and Application

Finally and this is the pillar that binds it together and makes it so strong.  We take time to reflect often, so much so that we become skilled in self-reflection and in giving feedback to others to aid their self-reflection.

I believe every team – not just technical teams should take a break and reflect regularly, no matter what you do, you can improve, but you need an environment conducive for that thought process. An hour away from your normal environment may end up being the most productive hour of your week if you can learn to reflect effectively.

Facilitating Retrospectives

Facilitating retrospectives is a difficult skill, getting past the noise to get at the real issues can be difficult and takes skill and practice, but both the facilitator and teams get better at this over time, especially if they reflect on how to improve this skill.

As a group and individually we should take time to identify learning opportunities, we continually observe ourselves and our teams looking for ways to improve. We learn to give and receive feedback in a way that helps us grow – not to diminish us.

We challenge our thinking, we question our beliefs and we look for ways to grow.

We learn how to experiment in structured ways trying new things and observing, we learn the value of metrics and measurements, both in our team and our products.

But the learning and reflection is for nothing if we do not apply what we learn, the application becomes yet another skill we can develop, may of us can become analytical and observant but continue to do the same things despite what we see.

If you always do what you’ve always done, you’ll always get what you always got

Learning to apply our observations and reflections in a structured an effective way is another challenge, and bringing this back full circle to systems thinking we should focus on the area that is holding us back the most and deal with that alone, and then repeat the process.

5-focusing-steps-113297

Trying to fix too many things or focus on too much at once can lead to confusion and particularly if you are measuring impact of changes if you change more than one thing it can be very difficult to know which one had impact.

Summary

All three of these thought processes overlap, intertwine and often depend on each other, but when bound together are extremely strong, and we can and will get better at delivering software and helping others to do it.

 

Advertisements

Are you working too much?

Would it surprise you to learn that the person in your team or company that regularly works 60 hours a week (and makes sure everyone knows it) is very likely the least productive person on the team?

The person working 60 hours is likely the least productive person on the team.

And I don’t simply mean that productivity diminishes after 40 hours, I mean absolute total productive output is less from someone working 60 hours compared to someone working less than 40.  The reality is that you would actually get more done by NOT working that time than you will working those extra hours.

This is a hard pill to swallow in a culture where ‘working hard’ is seen as a virtue, and the more hours I work the more virtuous I am. Long hours are often assumed to show commitment, dedication, loyalty. Maybe they do, but they don’t show productivity. If your company values those things above actual productivity then so be it, but understanding that it is about those attributes rather than productivity is a rather brutal fact to face. However, if you want to produce more and maintain high quality then you need to work less hours.

Parkinson’s Law

I am likely to offend a few hardworking people with this but my assessment of the findings of these studies is that is is a subconscious manifestation of Parkinson’s law. “Work expands so as to fill the time available for its completion” If I expect to work 60 hours then I’ll make my work last 60 hours.

parkinson 2

Not just a European thing.

Europeans have a reputation for favoring reduced working hours and I’m sure it is an ongoing frustration to those in America that despite typically working more hours, American companies are consistently similarly or less productive than their European or Japanese counterparts despite the longer working hours and less vacation.
Interestingly, the study was actually a 12 year study by the Ford Motor Company of production in the USA.

Henry Ford… again.

Before I go into the study in more detail I’d like to go back in time and talk about the history of working hours and in particular Henry Ford.

If we go back 150 years there were campaigns all over the world to reduce the working week from 16 hour days, 6 days a week – 96 hours was considered a normal working week for many. Forward thinkers pushed for limiting the working day to 10 hours with breaks for food – a radical concept at the time.

MayDay

Over time much of this became law despite fierce objection from industry, and by 1914 a normal working week was 9 hour days, 6 days a week.  The pressure until then mostly came from humanitarian motives and agendas, and perhaps because of that, businesses took steps to prevent it taking hold, reducing pay in line with reduced hours so a reduction of 20% of hours came with a reduction of 20% in wages, this undermined the whole movement.

But then came Henry Ford. Ford created the 5 day working week, and a limit of 40 hours, but best of all he did it for profit and not for social good.  At the time his factories worked 6 days and 9 hours a day (54 hours per week) just like everyone else, but he reduced working hours by 25% and instead of cutting wages he doubled them.

The productivity increases resulting from reducing hours were so significant that Henry Ford was attacked by the Wall Street Journal “To double the minimum wage, without regard to length of service, is to apply Biblical or spiritual principles where they do not belong.” going on to say “in his social endeavor he has committed blunders, if not crimes. They may return to plague him and the industry he represents, as well as organized society.”

51098603-f186b080bc53f64bbbd46208f7dec61a538631e4-s1200
Henry Ford may have paid his workers a good wage, but it wasn’t out of charity — it was a good business decision that some say helped the middle class take off.

As you can imagine his competition was not happy either, paying more for “less hours” was maddening, but what really made them mad was that productivity jumped up massively. People simply couldn’t get their heads around the idea that less hours  increased overall productivity.  Slowly the competition copied Ford and got the same results, productivity went up for less hours, and eventually this carried across to office workers too. But even with those starting results and seemingly unquestionable evidence we stubbornly cling to the notion that more work is more productive.

I have written more about Henry Ford here.

Back to the present.

Last time the proposed reduction in hours was met with hostility but eventually it was seen as beneficial to everyone, especially the business owners that fought so hard against it.  Once again studies show that reducing hours will increase overall productivity, and once again industry is pushing back on it in the face of the evidence. Challenging established culture with only facts is apparently not an easy battle.

Studies repeatedly show that long hours (40+ hour) results in reduced productivity, reduced quality and a less healthy lifestyle, and yet society still perceives the number of hours worked as a measure of hard work.
It is as if we see more value in the hours worked than the output of their labour.  Someone that works 30 hours and produces 30 widgets  is seen as less valuable than someone that works 60 hours and produces 25 widgets, because he works so much harder.

In our culture we see more value in the hours worked than we do in the output of our labour.

How did we get into such a mindset and how do we challenge that way of thinking.  Surely we should reward the more productive and effective person? But we don’t, we reward the inefficient, we lift up Jane for being here at 7:30  PM finishing up his work and we criticize Anne who got all her work done and left at 4.

Part of the problem, especially in knowledge work, is that productivity is not easy to measure, just like quality and mistakes are hard to quantify.  So rather than focusing on what is important we focus on what is easiest to measure – number of hours in the office, it is ironic that in our laziness in finding effective measures we end up working longer hours.

So what about overtime?

There is more bad news in the 12 year study by Ford they found that overtime (over 40 hours) results in reduced productivity in the long term.  40 hours is the very limit of maximum total productivity for a manual worker, this applies in both the short and long term.

Short term (less than 3 weeks) there are productivity gains for working beyond 40 hours, but after 3 weeks those gains disappear and actually reduce productivity afterwards. Even just 2 weeks of overtime and then stopping results in more loss in recovery than the gain made in the short term boost.

In other words, yes you can make a short-term gain using overtime to meet a deadline, but it will cost you more than you gain over the following weeks. So use it wisely and expect a recovery period.

Bad news for knowledge workers

For knowledge workers the news is worse still, the point of peak productivity is under 35 hours, and any hours above that are actually damaging, quality is markedly worse, mistakes and resulting corrections mean that productivity reduces dramatically when knowledge workers work beyond 35 hours, primarily because fatigue, stress and concentration have a profound impact on the quality rather than the quantity of work. We simply cannot be creative when tired, we struggle to solve problems come up with ideas or compose constructive discourse and debate, we are actually very likely making things worse not better and the clean up cost for knowledge work – bad decisions, introduced bugs, stifled creativity is far more damaging than not being there.

Worse news for Lawyers

Lawyers are typically in an unfortunately situation where they bill by the hour rather than by quality or even quantity of work. They are essentially encouraged by their business model to be unproductive (not consciously, it is just a product of the business model). Essentially a 60 hours week for them is the result of rewarding bad behavior, if you pay for time they take more time, pay for productivity and we become more productive. We also reward with status the hard working guy that is willing to sacrifice his weekend for the appearance of working harder. More encouragment of bad behavior.

In ‘bill by the hour‘ work environments it is a challenge to change the model, productivity is hard to measure – even if we see stress, mistakes and problems taking longer to solve. So it is hard to convince clients that working less is more productive, especially when it means charging more, and it becomes even harder when we can’t even convince ourselves because this notion is so culturally ingrained in us.

What now?

It is pretty simple really if you want to maximize the productivity of your teams, then reduce their maximum working hours to less than 35 hours (without reducing pay).  They will work harder and more effectively for five 6-hours days than they will for 8 or 10-hour days. Your overall productivity will be higher.

Or work 8-hours, 4-days a week and you will find your teams will be more focused, more energized and and noticeably more creative.  They will be happier, harder working and make less mistakes.  They WILL get more done and it will be higher quality and more creative. They will also be refreshed have a happier home life.

Or we can ignore the brutal facts and continue to pretend that working long hours is a good thing, and praising the guy that works 60 hours a week and yet produces less than a part-time worker.

Note: my wife finds this particularly amusing as I work long hours and when I’m not working I’m blogging and when I’m not blogging I’m working on my game or running meet ups – there is a significant degree of hypocrisy and self-denial at play here.

Summary

Let’s not underestimate the difficulty here, this is a complex topic, and it is unlikely to be accepted any time soon, there is a lot of resistance – and that resistance is not based on a lack of facts or data.  There are numerous studies on this topic, all with the same findings.  Oddly enough despite the strong resistance to this idea, I couldn’t find a single study that didn’t find that overall productivity went down when hours went above 35-40 hours.  There were even some studies that showed that regularly working 60 hours resulted in the same number of mistakes and level of performance as being drunk.

(If you see a study that contradicts this please share it, I spent quite a few hours on this but couldn’t fine one – and no, the contradiction has not escaped me.)

Decision Makers

Decision makers typically work longer hours and it is effectively their money, asking them to pay more for the perception of ‘less‘ work is never going to be an easy decision.  We come from a puritan culture where we make a cultural assessment of someone based on effort not outcome. Deep-down we know this is not objective, I think we know this is wrong, but culture is not based in logic and changing culture will take more than facts and figures. It needs someone like Henry Ford to lead the way again.

 

 

 

 

Mindset or method?

Straw poll:

Should we teach practices and methods in the belief that an Agile mindset will evolve from the good practices?

or

Should we teach an Agile Mindset in the hope that with an Agile Mindset good practices will emerge?

Related image

I know of a few Scrum Masters and a few Agile Coaches in each camp, and some that feel very strongly on this topic. And of course the choice lies at the heart of most Agile Transformations and the outcome will therefore be far reaching.

Method over Mindset

Around 10 or 11 years ago I was introduced to a new way of managing projects and a new software tool for doing it. I was trained in how to use the software, but not in the theory behind the tool.

We are what we repeatedly do. Excellence, then is not an act but a habit.

– Aristotle

The tool was amazing, it really blew my mind. As a Project Management tool/method it made more sense than anything I had used previously and I loved it, I happily used the tool and got good results. But despite having the tool I never learned the theory and didn’t even know where to look to find out more.  No lack of interest or enthusiasm but I was content to use the methods and it helped in my current situation but I was never able to make the leap to more than a method despite my enthusiasm.

It is a little beside the point but the tool was Critical Chain for Project Management and before I was introduced to Agile I thought this was the best option out there for Waterfall projects (probably still is). Sadly despite it being so great, it was still based on the assumption that the end state was known at the start of the project, which for me is the ultimate failure of Waterfall thinking, and my primary reason for moving to Agile.

Only much later did I discover the theory behind the tool was The Theory of Constraints and the 5 focusing steps, IF only I had been shown that and I feel my enlightenment would have come much sooner.  But a method without understanding the theory leaves you unable to adapt and improve, I was limited to the context in which I was shown.

What is more I had a co-worker that struggled with the concept of slack and wanted to follow the method apart from that one aspect – the lack of understanding left him unable to differentiate between a necessary aspect of the method and an arbitrary one, and ultimately for him the tool didn’t work because he rejected the necessity for slack.

A lack of understanding of the theory leaves you unable to differentiate between a necessary aspect of a method and an arbitrary one.

– John Yorke

1cf58fa9895dafded2997558ab348190

Method over Mindset, the Return on Investment

Another consideration is that teaching theory takes considerably longer and has a much lower conversion rate. That is to say that I could teach the Scrum framework fairly quickly – a matter of days, and be pretty confident that the instructions are clear and ‘could’ be followed effectively. To take that same group and to teach them the theory to the point of understanding the why behind each of the practices could take weeks or months, and likely longer before they are fully understood. It is also possible that some will never grasp the theory but are still perfectly capable of being good team players.

Continuous improvement is better than delayed perfection

– Mark Twain

Many organizations are interested in the short-term results rather than long-term understanding and so there is a desire to do the least for the most impact. So we see the evolution of phrases like ‘Scrum-but’ as a means to discourage deviation from the defined framework. Our goal becomes to repeat, rather than understand.

Mindset over Method

cropped-serres-view-4.jpg

If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea!

– Antoine de Saint-Exupéry

The flip side of this is the desire to teach/show the impact of having an Agile Mindset and then having the individuals identify a solution using that knowledge.

Clearly this is a much greater challenge, even those with an Agile Mindset will initially lack any practical applications to draw upon, even the most Agile of mindsets is limited to what they have experienced or read about, and contriving a new bespoke process to your environment may ultimately be the most desirable solution. However, it is impeded by the ability to share that vision and understanding with others, and limited by your understanding, ability and creativity.   And frankly do we really think that we are able to come up with a better framework than Kanban or Scrum on our first pass at an Agile Transformation?

A middle ground?

As you have probably guessed I am not a fan of either approach. I believe that most people will not become Agile overnight and even the most eager of minds will take time to absorb and understand the implications and possibilities of Agile.

I further believe that teaching Scrum as a closed framework that must not ever be deviated from is not the solution. Instead I would compare it to learning any new skill, we teach good practices and when you have mastered them you are ready to move on, we may teach a variety of good practices so you have some comprehension of the possibilities available, that way you do not limit your thinking so just one solution.

But we learn to master the basics, and we learn to question ‘why?’ when we feel we have mastered the basics and we understand why, only then we are in a position to start to evolve.

Applying Lean and XP and Kanban to the Scrum framework can let you grow in understanding within a safe set of guidelines. And when you understand the mindset enough to comprehend the limitations then maybe you are ready to craft your own solution.

If you can’t explain it to a six year old, you don’t understand it yourself.

― Albert Einstein

 

Why I recommend Scrum

Personally I love Scrum as a foundation for a transformation to Agile for those undertaking software development projects, not because I believe it is better than Kanban or other tools, but because to succeed with Kanban you need a level of self-discipline and understanding that is often absent for those new to Agile, and it becomes far to easy to gold plate or run long.

Scrum adds some safety nets and feedback loops that counter many of the usual “human nature” problems that arise from teams new to self-organization. Self-organization is a skill we need to learn and develop like any other. Scrum is so simple to learn, and easy to follow (if you are willing) and once you understand the Agile mindset it is a great framework for evolving into a great Agile team. But like any tool if used inappropriately you can make a mess. But any change requires a good guide.

That being said for support or reactive work Kanban is ideal as the discipline generally comes from outside. It is never a one size fits all.

Leadership

Method without mindset can only take you so far

Teaching the mechanics without teaching the theory is only half the task and whilst it is sufficient for many consultants to get paid, what they leave behind is a culture unable to improve, and without improvement entropy will set in.  I believe both some guidance on the mindset and instruction in some methods are both necessary for a successful Agile Transformation, along with a healthy amount of enthusiasm and patience from those leading the transformation.

 

 

 

Is culture observation or aspiration?

There has been a lot of talk recently about culture and it’s importance when creating organisational identity,  but there are two ways I see for an organisation to create a culture.

A short story…

I was once told a story of how the British and US army engineers take two different approaches to footpath planning when creating their bases.

Flag_-_Union_Flag

The British planned in advance and they laid the footpaths to a defined route and the soldiers were required to follow the specified paths, and were corrected if they didn’t.

71X+wfQBpKL._UX385_

The US engineers on the otherhand would delay laying the footpaths until the base was in use, they would observe the routes taken and where the soldiers walked and would lay the paths when the preferred routes were clear.

The belief (or so I was told) was that people will find the most efficient route on their own.

Each has it’s own merits, and is itself likely a reflection of the culture of those two organisations.

A deliberate culture or a reflective culture

I see this as being very similar to a company’s culture. You have two main choices: either you decide the culture you want, you lay it out and then make decisions that reinforce the path you set. This means hiring practices, rewards, punishments, recognition, and everything in between, you continue to do this until the normal behaviour is to follow the path set.  Your culture is by your design. But to get the culture you want requires a lot of correcting of behaviour until it happens.

Or the alternative is to wait and see, behave the way you behave naturally and the same for the others around you, soon enough a culture will form and it will be a culture that reflects the way you behave. The good news is this is your real culture, the bad news is – this is your real culture.

There are problems with both of these, choosing a deliberate culture that goes against some of your natural tendencies or is unrealistic can lead to it not being followed and the result is that you claim one culture but actually have another, this can be very damaging especially to those that believe in the defined culture.  If you follow the rules but others get ahead by other means it can be corrosive.  A lack of defined culture can also bad as there is no safety check on poor behaviour, left unchecked it quickly becomes the norm and then it becomes your culture, which is the case for women in IT.

Women in Tech

One great example could be seen with Women in Tech, where most companies would say their culture does not set out to exclude or marginalise women, but without a deliberate culture to seek out diversity we have allowed the lack of diversity to become the normal state and for the culture to be one that unintentionally discouraged or excluded women. Often evolving from small companies that have grown by surounding themselves with like minded individuals. Unconsciously biased towards those similar to them.  It will take time and effort and a deliberate culture to break through some of those barriers we have created over the years.

But this is seen in all aspects of an organisation, if your culture tolerates something for long enough, maybe because it is easy to ignore when small, it can become a much larger issue when you grow.  If you are not explicit about the culture you want then you may not be able to shape the culture you have. In larger organisations sub-cultures can form in different areas and this can be even more damaging, without a clear global culture factions develop and the inconsistencies undermine the larger whole.

Agile Transformation

One of the reasons that Agile Transformation is so hard is because it is a culture change rather than a process change, you are defining a new culture and that will not happen overnight. All the previous actions that were normal, the rewards, the metrics the measurements are very hard to undo.  Empowering people to be self-organising when they have only known command and control will take a while to adjust.  I believe this is why so many agile transformations are unsuccessful, some processes are changed but there is no desire or will to change the culture, there is a general wish to change to Agile without actually changing.

The solution

The solution in my opinion is to do a little of both.  Be aware of the culture you want and be explicit about it, shout it from the rooftops, and repeat it and repeat it and repeat it, until everyone in your organisation knows you mean it and you believe in it, be clear where you aspire to be. This will still take a very long time to have impact.

But also be aware of where you are now, the unwritten culture you have now is just as strong and just as real. Be especially aware of the behaviours that your culture currently has that you are not happy about.  If you are honest about your weaknesses and failings you have a far better chance of changing. Seek out and coach those that are not behaving the way you aspire to be, remember they behave that way because it is your culture.

Culture change wont happen overnight but that doesn’t mean you shouldn’t be intollerent of any behaviours that don’t reflect the culture you want.

Are you ready for the fallout?

There is an old saying – An Agile Transformation is easy, you only have to change two things: Everything you say, and everything you do.

But actually, as obvious as that joke was, it is also wrong. You only need to change one thing, you need to change the way you think.

Project or Product

It is my premise that when we talk about Agile Transformation what we mean is transforming our thinking from considering our deliveries in terms of ‘Projects‘ to thinking in terms of ‘Products‘. And transforming from measuring people in terms of their effort, to measuring them in terms of their collective contribution to a shared goal (the value they add).

Projectan individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim.

Productan article that is created or refined to satisfy a need.

As we have all discovered, software product development is complex, both in the development itself where we face a host of unpredictable variables, complications and unknowns. But, more significantly, it is very difficult to know what you want until you see it and consequently there are an abundance of quality software products that do not effectively fulfil the need that triggered their commission.

We have learned that reviewing progress regularly with stakeholders and modifying based on that feedback is far more likely to result in a successful product.

In most cases is is a fallacy to believe that for a complex and bespoke software solution you can know your end state before you begin, regardless of how well you analyse. And no matter how good at planning you are if you don’t know the end state your plan is flawed, and as you cannot predict the unknown even the best plans are unreliable.

We have come to realise that bespoke software delivery is far more akin to product design and development than it is to project delivery.

Management is doing things right; leadership is doing the right things.

Peter Drucker.

Agile Transformation is about moving from Management to Leadership

Peter Drucker is an inspiration here, traditionally we put so much effort into getting things right, to be more efficient, or to do this, by that deadline. That we forgot to ask if what we were doing was bringing value. We put all our emphasis on measuring and monitoring effort, or efficiency, rather than assessing if we are achieving our goal.

If you are considering an Agile Transformation it is likely that you have discovered that efforts to ‘manage‘ projects is leading to the wrong results and the focus needs to move from a focus on effort to a focus on value. To set a direction and ‘lead‘ the way in product development.  Try to stop measuring output and to start measuring outcomes.

Impact on Project Managers and Business Analysts

But this is a major cultural change for many companies and not an easy one. It is a complete shift in perspective, moving from planning the delivery of a project to collaborating on the creation of a product.

It is particularly difficult for Project Managers.

For project management to be effective the end state needs to be [largely] known, and for the steps to get there to be familiar and [largely] predictable. With a known end state and predictable building steps, a Project Manager can effectively work towards that aim.

But bespoke software is far more complex and is generally dealing with many unpredictable variables, the biggest variable being the end state. In the majority of cases the end state is not known at the outset and emerges in the course of the product being developed. The true end state needed to fulfil a need or want can very often be significantly larger or smaller than initially anticipated.  The ability and flexibility to pivot based on emerging information is crucial for delivering value and the product being a success.

Business Analysts similarly must adapt, project planning generally relies on a knowing as much as possible at the time of planning, and so there is heavy reliance on the Business Analyst. Product Development is again a mindshift for a Business Analyst, there is no longer a need for detail up front, in fact in most cases it is a waste due to the likely and frequent change of direction and priority as we learn so much as the product emerges.

Business analysis in an agile software product development means an early assessment generally at a high level is all that is needed, with detailed analysis happening much closer to when the work is done,  at this point much more is know about what is actually needed and so we are not wasting time analysing something that will not be done.

An Agile Mindset

Agile is a mindset far more than anything else, and when you start to look into it, there is nothing new, nothing original, and you will be surprised to find that whilst the word Agile has been used a lot by the software industry in the last 20 years or so, the practices and behaviours are just the good practices and behaviours of general management going back a century and possibly even a millennium or two.

‘Agile’ as we have come to know it whether we mean Scrum, Kanban, Lean, Lean Start-up, or any of the many other Agile frameworks is, in most cases a collection of historic good practices and guidelines identified by successful leaders and businesses in the past, they have been collected under one umbrella polished up a bit and marketed – very successfully – which is likely why you are reading this.  I say this to discourage the notion that ‘Agile’ is new and untested, there are certainly some misinterpretations and misapplications but the underlying principles are sound and based on a lot of experience.

Just as an observation, if you looked back at the early days of the Ford motor company as an example from over 100 years ago, and you assessed them against modern standards of agile my guess is that they would hold up very well.

Agile Transformation should not be your objective

Agile Transformation is often presented as the objective, when in reality it should be a strategy to reach a goal. Taking some time understanding what your goal really is, will make any transformation far more likely to succeed.

  • Are your customers dissatisfied?
  • Are your products missing the mark?
  • Do you(or your clients) feel you are not getting value for money?
  • Are you slow to market?
  • If you are creating software products for internal teams are they not having the impact you expected?
  • Are people circumventing your tools?
  • Is your ROI on software development too low?
  • Are you losing key development staff?
  • Is there a lack of transparency in the software development process.

These are just a few of the many reasons a company may want to undergo an Agile Transformation, they are all global business issues, and that is a key point: Agile Transformation is not an initiative just of the software department, it is a change for the entire business. It is a major cultural change that will impact your business from top to bottom. From the way you sell your products, to the way you hire staff, and particularly to the way you measure success.