The good the bad and the ugly of agile

4. *Respondents were able to make multiple selections. *Respondents were able to make multiple selections. 6% Not applicable/ Don’t know 38% Lack of management support 33% Unwillingness of team to follow agile 30% Insufficient training 33% A broader organizational or communications problem 36% Lack of support for cultural transition 37% External pressure to follow traditional waterfall processes 42% Company philosophy or culture at odds with core agile values 44% Lack of experience with agile methods philosophy or culture at odds with core agile values at 42% and lack of support for cultural transition at 36%. BARRIERS TO FURTHER AGILE ADOPTION At the agile initiative level, respondents cited organizational culture or a general resistance to change as their biggest barriers to further agile adoption, followed by not having the right skill set. 44% Ability to change organizational culture 35% Not enough personnel with the necessary agile experience 34% General organizational resistance to change 32% Pre-existing rigid/waterfall framework 29% Management support 24% Management concerns about lack of upfront planning 23% Business/user/ customer availability 22% Concerns about a loss of 16% No barriers 15% Conﬁdence in methods for 14% Concerns about the 13% Development team support 12% Perceived time and cost to 11% Regulatory compliance Leading causes of failed agile projects *Respondents were able to make multiple selections. 6% Not applicable/ Don’t know 38% Lack of management support 33% Unwillingness of team to follow agile 30% Insufficient training 33% A broader organizational or communications problem 36% Lack of support for cultural transition 37% External pressure to follow traditional waterfall processes 42% Company philosophy or culture at odds with core agile values 44% Lack of experience with agile methods BARRIERS TO FURTHER AGILE ADOPTION At the agile initiative level, respondents cited organizational culture or a general resistance to change as their biggest barriers to further agile adoption, followed by not having the right skill set. 44% Ability to change organizational culture 35% Not enough personnel with the necessary agile experience 34% General organizational resistance to change 32% Pre-existing rigid/waterfall framework 29% Management support 24% Management concerns about lack of upfront planning 23% Business/user/ customer availability 22% Concerns about a loss of management control 16% No barriers 15% Conﬁdence in methods for scaling agile 14% Concerns about the ability to scale agile 13% Development team support 12% Perceived time and cost to make the transition 11% Regulatory compliance Barriers to Further Agile Adoption

8. Scaled Agile Framework™ Big Picture

9. Scrum Process 1 – 4 weeks 24hrs Product Backlog S P R I N T Poten7ally Deployable Increment Daily Scrum Done since yesterday? Plan for today? Barriers? Sprint Review Demo completed features to all stakeholders Sprint Planning Review Product Backlog Build Sprint Backlog Commit to selected scope Product Backlog Priori6sed features desired by customer Sprint Retrospec7ve How did we do? What can we improve? Vision Vision Aim of the project With a business owner Sprint Backlog Product /Project Roadmap Release Planning

10.

11. “Everybody is a genius. But if you judge a ﬁsh by its capability to climb a tree, it will live its whole life believing it is stupid” Albert Einstein

12.

13. I felt a great disturbance in the force. As if a million voices suddenly cried out in terror where are the tests

14. Agile Should Give Us Feedback Inputs OutputsSystem Time Before After

15. Scaled Agile Framework™ Big Picture

16. Nega6ve Feedback is Needed! Situa6on at the start Explosion Blocking No Goals t Posi6ve Feedback Situa6on at the start Goal t Nega6ve Feedback Situa6on at the start

17. Increment or Iterate 1 2 3 4 5 1 2 3 4 5

18. Velocity •  Velocity – The speed of something in a given direc6on Speed we do but the ‘given direc7on’ takes eﬀort to achieve.

19.

20. Babel The Language of Agile

21. Scrum SCRUM Mee6ng. Takes a long 6me Lots of hot air Goes nowhere!

22. Backlog

23. Sprint What do you mean we’ve got to go again!!

Editor's Notes

How Prince2, MSP MoR, RUP, SaFe, Scrum and Enterprise Scrum are implemented by people in organisations. All of these are models. There are two things I can remember from my modelling lectures Transition: The new model to what they do. Transition what they do to the new model. “Give me an agile QMS” Ivar Jacobson was giving a key note a few years back. He said he brought RUP into the world. And was proud of the child. But like a lot of children it had grown up into a hooligan. What happens to these frameworks? Leo Tolstoy “The most difficult subjects can be explained to the most slow-witted man if he has not formed any idea of them already; but the simplest thing cannot be made clear to the most intelligent man if he is firmly persuaded that he knows already, without a shadow of doubt, what is laid before him.” Part of the issue is our Human Nature – we tend not to listen properly to others and we certainly assume what people are going to say to us before we start. We are also conditioned in education – there is a right or wrong answer. The answer is whatever gets me the marks for the exam not what is most appropriate for this particular situation – our education systems are successfully training in particular fields but are failing to create thinking individuals. We need people to advance thinking and take us forward into alternative ways of doing things. It gets worse we even take words and concepts and change their meaning. E.g. User Stories become requirements statements and before we know where we are we have a 70 page User Story document that has been transposed from an existing statement of requirements. Scrum of Scrums as a governance and prioritisation forum. (Even as an management role) We have Daily Stand Up meetings turning into daily progress reporting meetings We have face to face communication and colocation turning into a control of people and a desire to have bums on particular seats for 7.5 hours a day. An estimate turning into a guarantee! Processes trumping people and their interactions. The destruction of trust The same is true for me as an agile change agent as it is for the leaders and the individuals within an organisation. Be wary of it and truly actively listen to what others are communicating and understand what they mean by the words they choose to use. Just because someone discusses Work Package Agreements does not mean that they are in favour of a complete implementation of Prince II and therefore to be side-lined. It means they have Prince II training and are using to express what they think needs to be done. The consequence is that we as agile people need to be familiar with different models understanding the language and concepts within them. I have more success encouraging Prince II trained folk to create a WBS that looks like a Story Map than I do in creating a Story Map based on User Stories.
How to solve Start small and simple. I can get my arms around an acorn. Once an acorn has grown to a full oak tree it’s a little more difficult!!! What if you already have an oak tree – Then it’s a power game. (Power is about creating a sufficient political coalition to challenge the blocking managers) Challenge as a singleton will result in failure
Don’t start here!!!! Unless you have to!!!!!!
Training but no mentoring / coaching Coaching but no training
Cross functional teams Selection processes Building teams so that people bring and use their best qualities. We’re all rubbish at something! “I don’t blame anybody! I only blame those who deserve it.” “Come on people, you have to have the guts to speak up when things aren’t right” “I have worked hard to stamp out the bullying culture!” “I understand what your doing, I think your doing a good job” - > I haven’t a clue about what your suggesting and you’re on your own. “I know it’s a difficult situation – but you haven’t used the latest template!” Does not mean you always have great people Johnny two weeks PMO The political player looking says your doing the right thing and then pushes you in the hole you’ve been digging
Projects that do not use or advance best engineering practice. Can’t invest in the environments for CI,BDD – costs too much! 20K a year for an environment is 4 days effort at £500 a day per developer!!
According to Version One State of Agile Survey. Velocity (points Delivered) is the most common way to measure success of an Agile Project!!! Release burn down is at 39% Business Value 19%
Governor from a steam engine. What happens to a steam engine without a governor? It will go faster and faster. There is no control, the pressure increases and the boiler explodes with devastating effects. Or the fireman will not notice the pressure decreasing in time to build the fire so the temperature decreases the pressure decreases and the engine stalls! Have you ever been on a project like that? The pressure increases and increases as the deadline looms and the team explodes in glorious technicolourful language! Or we fail to notice that no value is being delivered and carry on burning money until eventually the project grinds to a halt having delivered nothing but spent a fortune! Juggling example. Agile projects often fail to give us the feedback. One key team member to facilitate this feedback is the Product Owner – without an available PO no feedback loop for the team. As we scale the number of teams working on a system. Care and attention has to be applied to the way feedback is generated. Team’s can become silos
System Feedback is noticeable by its absence! I was doing a talk to a Programme Management community a few years back. The slide I used then was a waterfall slide and like/unlike you they reacted by saying there was lots of feedback in waterfall. Check the Specification against the requirements. Check the design against specification Check code against design – peer reviews etc etc. They described all the Verification techniques that we have used over the years. Question - who understands the difference between Validation and Verification? The two words have been used together to represent the full range of QA activities for as long as I can remember. According to CMMI Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610]. Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610] According to CMMI neither are about feedback. Validation during the process possibly is about feedback depending what is being done. Validation at the end of development is too late for feedback that’s simply recognising we have an explosion or a dead engine!
My PM friends are right. There is feedback in waterfall in control terms it’s positive feedback re-enforcing the systems desire to explode or stop. In system control theory for a system to be in control it needs –ve feedback to bring it towards a goal. E.g. A thermostat within a heating system. Agile through Deming’s cycle and incremental goals that create business value that can be owned by business applied holistically gives us that negative feedback. However some agile implementations do not have that negative feedback. Why, because its hard!!! Product Owner within Scrum is the potential provider of that feedback. All too often they are the wrong person, they are not empowered, they’re an IT supplier provided BA who does not fully understand the business needs or are not empowered, there is no feedback link. This has to be holistic – anything less than Business need as the input to our delivery system will break this and bring us back to the world of +ve feedback.
Ruins of the Tower of Babel in Iraq – at least some architects believe it to be. I have a problem with language we use to describe agile. The reason is because I have to explain what we mean by terms!
Add Stand Up – is it appropriate for people with disabilities?
Speed I accept, but the ‘given direction’ piece takes effort to achieve. I often see high velocities but little progress towards goals. The speed is good, but the direction of that effort isn’t. Velocity implies we are doing the right work to move towards the goal and that, unfortunately, isn’t always the case.
Backlog An accumulation of uncompleted work or matters needing to be dealt with. Great! Let’s start off with a concept of perceived debt. Straight away it looks like we are behind schedule and we haven’t even started yet! It’s a pretty negative term in my opinion.
Sprint- Run at full speed over a short distance Are we trying to do this? No we are not. We require sustainability. We don’t want an Usain Bolt who can create fantastic results for 10 seconds then collapse in lactic shock. We want a Seb Coe who can run on and on. Sustainability is key, and you don’t get that when you try to run as fast as you can.
Show and Tell –My 4 year old son does this at school! Wikipedia says that this is common in early elementary education supporting my initial reaction. It’s a very important element of the feedback loop mechanism we value, but the term sounds so childish. I do know there are alternative phrases used such as demonstration or review, but I still hear Show and Tell used all the time.
Scrum Master – Well I am not going to even bother with the dictionary here. Everyone expects Scrum Master to wear his or her pants on the outside and sport a flapping red cape. It’s even worse than a Six Sigma Black Belt and that’s saying something! Is it a sexist term – certainly not inclusive. “Master” Google for images on the term Scrum Master – what is the ratio of the sexes.
Extreme Programming – ‘Extreme’ isn’t a word usually associated with confidence. For example, Wikipedia describes Extreme sports as ‘a popular term for certain activities perceived as having a high level of inherent danger’. It inspires utter fear in people.
Planning Poker – I love this tool. A great collaborative and educational mechanism for getting inexpensive informed estimates. Great stuff. But it isn’t Texas Hold’em! OK so we use cards but to imply it is gambling doesn’t inspire confidence in my opinion.
Yeah – I want some –ve feedback in my delivery system. Lots of firms have undertaken massive transformation projects to obtain -ve feedback Most firms admit to using Agile techniques yet there still seems to be a disconnect between the needs of the business and the delivery of IT. I will tell you a story of the sower 1st told over 2000 years ago – I think it will give us some insight. This parable is about change and I would like to use it as a metaphor to see what happens during an Agile Transformation.
Dealing with geographical distribution - though it strikes me that this is a generational problem that will disappear as the 'old fogeys' leave the industry. My 14-year-old son has no difficulty in collaborating with team-mates in multiple locations on tasks that require close collaboration, teamwork, communication and adaptability to changing circumstances. He does this through using a mix of voice communication, instant messaging, use of tools that provide a shared viewpoint of a situation, etc. Of course, his objectives are primarily about killing hoards of zombies or capturing an enemy encampment, etc. but to say "we can only work effectively together if we are sitting in the same room" is an age-related phenomenon with a limited lifespan.
Working with outsourcing partners - especially if the only advantage at present is availability of low-cost resources. Agile and 'Governance' - accepting that some governance, be it architectural, financial, etc. is required at the enterprise level - I know that there are presentations on this topic at the conference and I am sure you have seen previous ones.
Business acumen so that we can engage our business colleagues as partners and collaboratively face the coming disruption. Engineering expertise on its own will no longer cut it. Organisational change – Agile should be the biggest business transformation undertaken it therefore needs a change management approach. Using Scrum as the change vehicle will only get you so far in a large organisation try Kotter Management Practices – Management 3.0 Jurgen Appelo - avoid it as an excuse for no accountability. Education – time to start teaching system thinking examples of BTEC advisory and Andrew’s can only test when the product is complete! Contracts – measuring value developing trust between supply and demand.
Economies of scale – It’s not just RMM

The good the bad and the ugly of agile

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to The good the bad and the ugly of agile

Similar to The good the bad and the ugly of agile (20)

Recently uploaded

Recently uploaded (20)

The good the bad and the ugly of agile

Editor's Notes