Tag Archives: Agile

Agile – It’s not about delivering working software faster

Posted on by

What is agile? Most cliched answer to this translates to “delivering working software faster”. Because, agile principles clearly states – “Working software is the primary measure of progress”. It doesn’t mention anything about the speed though. In rest of the article, where ever you see “value” translate it to “shed-load of money” if that works for you. It is very important to establish what is the definition of “value” for you, to understand the true meaning of what agility is.

If you buy a new bike or car, it’s performance will always be lower than a well oiled 2year old vehicle with similar specs. Agile teams are like that. The team members can be experienced and brilliant but to really know what part of the product is making the most value, requires investment on thought process. That’s where a Product Owner/Expert comes in with data to prioritise the most valuable work on top of the backlog and own the decision. It’s their job to also convey “why” it is more valuable to the team as well to validate the possibility.

Example Problem Statement

A company hired 10 team members paying £500/day. Screw prioritisation; an expenditure of £5k/day needs to be used up in anyway possible on that 8hrs contracted. Even if that means we make the member work on items no one really give a shit about or have any value. If we focus on priority we will end up wasting 3hrs a day, out of which the members will celebrate a 2hr lunch and will be milking the strategy. How do you propose to handle that?

Solution

Assuming a 20 days working month, paying £5k/day or £100k/month is actually a lot of money to go down the drain, if they work on features no one asked for. The cost can only be justified if they focus on the most valuable item first, instead of an item you may not need for a month. In many cases, as much as 80% work remaining are actually not necessary for early feedback, as the most valuable 20% decides the fate of a product. Work on them first and save your time and money and stop focusing on what the members are doing, as long as they are working on the right thing you require.

Pareto Principle

Does the above solution sounds familiar? Yes, I am referring to the Pareto Principle which is known for a century now. Albeit, saying that 4:1 distribution is “accurate” would be a wrong generalisation as it’s application varies. But it does make a point about how we should approach the product backlog. Empiricism, hence is the only way to go with faster feedback to continuously update the backlog as we know more and more about the product and end user’s expectation.

Source**

 

Working software is mandatory but the trick is to convey the message like this –

Agile is NOT about delivering working software faster, it is about delivering the most valuable software faster.

End Note

Prioritisation is all that matters. If you have adopted “Agile” and still focusing on speed or amount of work for monitoring purpose, then you are doing it wrong. There, Agile defined the way most businesses want to hear. Value can have different definitions for different businesses, “Money” being the most common form, which we should really focus on.

Hope this article makes it clear why “Agile” makes sense in development.

Velocity – a fallacy often blamed on Scrum

Posted on by

Overheard someone saying the other day – “Point based estimation is still a pointless metric and so is the velocity calculation in Scrum”. Yes I strongly disagree, not because I believe in the fallacy called velocity but because it has nothing to do with Scrum or being agile. Scrum is not a silver bullet, agree, but that comment clearly indicates a misguided anti-pattern. I am not a Scrum fanatic unless I wouldn’t create XDE, but this concerns every Agilist out there. It is about the trend of misinterpretation and the habit of many professionals to modify an immutable framework.

Scrum being a framework (not describing a method or practice) is being misinterpreted by many even after it’s 20 years of existence. While many organisations are still learning and implementing Scrum, we see more and more discussion around “Velocity” and “Point based estimation” which is not even part of Scrum in the first place (no mention in Scrum Guide).

Capacity is what we should focus on, not Velocity.

Velocity calculation is a result of the point based estimation techniques, which are also misused as a performance metric. Ask an average Scrum team how they measure team performance, the first word will be Velocity. Be it linear or relative estimation, when we use a number for anything, our beautiful minds translates it to an “absolute value” which is not negotiable. We start writing it in a card or add it on a tool to track velocity. Then we slowly & voluntarily dive into deeper political horizon of team velocity comparisons, false sense of predictability to never come back out again.

Intention of point based estimation is to break the ice.

Technical experts are usually shy, they love to just to get it done, write the code or test while listening to their favourite music. Estimation sessions gives them an opportunity to open up and be valued for their knowledge. They agree or disagree or share a fact that no one thought about before, to establish a shared understanding. Then they leave the room to start working on it but never leave the number behind. It stays in the card/tool and makes them uncomfortable when they find out a hidden issue which will screw the estimated number. This is frightening, as it becomes a matter of their honour and a measure of their knowledge, which makes them look retarded in front of their team.

“We said it’s 5 but now it seems like a 13, WTF ! If I tell the team they will think I am stupid.” – This, we can live without. This stops us from being brave and fail fast as failure is not an option. To be agile we need to embrace failure as learning opportunities. This negative Hawthorne effect goes against agility and get blamed on Scrum because of the time boxed sprints where velocity really applies.

We “estimated” the avg. velocity as 40 but it somehow becomes a “promise” to stakeholders which is not open for negotiation in many cases.

It creates an obsession among us to match the velocity every time or more to show off. Truth is, Velocity can easily be manipulated and somehow the “people” aspect get thrown out the window. Where is the trust? Where is the working software? That’s why, even though the point based estimations and velocity calculation were created to “guide” us, as human beings we cannot trust ourselves on showing our true nature – urge to control the uncontrollable. Therefore, to become agile we have to let go of this metric from Scrum, for good. We don’t want to be that person who focuses on these numbers and not outcomes.

Let’s get back to the basics of Agility

  • The fact is, we try to measure the scope in units like time, but we can’t. That doesn’t mean we have to use numbers. Be creative and find another way which doesn’t promote false sense of control over the development cycle. It’s development not manufacturing, you will fail many times before finding the right product. Scrum is for development not manufacturing.
  • RTFM – there is a reason Scrum has a guide so stop associating Velocity and Estimates as a “mandatory” Scrum metric while implementing. You are digging your own grave by doing so.
  • Stop asking Scrum Masters to report velocity as a metric. Even if they are in place, they are private to the teams, not open for all.
  • If you can’t negotiate, you are NOT agile. You might as well do Waterfall, it will give you the same results.
  • Stop making “Promises” on deadlines using velocity. If a person have never worked hands on in a code base, their knowledge about the product is at best worthless. If that person is making promises by predicting velocity, the joke is on them.

End Note

Velocity is a fallacy, whether you like it or not. Use it only if you are still winning. If you are failing then please let it go, just don’t blame it on Scrum. Scrum is much powerful without it.

Definition of Done (DoD) in XDE Framework

Posted on by

In my last post about Definition of Done (DoD) – The Holy Cow Approach, we have seen how “Done” can be misinterpreted just because there is no set definition for everyone. We have ways to deal with DoD by agreeing together what is Done before starting work on a User Story or any form of backlog item. This definition therefore can change depending on context, product, team or even client demand.

What if we don’t have to go through this never ending debate of defining a done for each work item? The internet if full of these discussion, agreement and disagreements which we can live without.

What if, we have a universal DoD which establishes shared understanding company wide?

Definition of Done (DoD) in XDE is a shared understanding

Xtreme Decoupled Engineering (XDE) has a beautiful way of replacing this small talk with something that adds real value – Delivery and End user feedback. In XDE, we don’t need to establish a ground rule about where to stop, before starting a work. We stop and call it Done when we get “a” user feedback – good, bad or neutral. If it’s good we celebrate, if bad we learn and if neutral we let the Product Expert decide where to go from there.

If this is not Simplicity, what is?

 

The One Rule in XDE makes sure we do not get distracted and the Delivery Expert being the Servant Leader of the 1R Team guides the bubble to focus on one work at a time. DoD is therefore universal to all teams and anyone interested to know the ETA of a certain value, don’t have to worry about what “state” it is coming out. It will always come out in a “Ready to Ship” state whenever it is done and wherever it is deployed for the feedback.

DoD in XDE invokes the boundary for Cycle Time measurement

Cycle time is the total time from the start to the end of the development process, which increases predictability especially if we are part of a Service Level Agreement (SLA). DoD in XDE takes help from the One Rule to establish these SLAs with predictable data over time to create a healthy metric to optimise the process. Here’s a visual which summarises how it work:

As we can see, the Cycle time is basically the duration which a 1R team takes to achieve the DoD following One Rule. It also promotes implementation of DevOps by an extreme reduction of multitasking and focusing on the end user feedback.

Conclusion

We have a tendency of making things complicated when there is a simpler solution. XDE’s definition of Done simplifies this ambiguous topic of discussion. An organisation can worry about bigger things which needs attention and teams can work towards the same goal every time like a second nature.

More about XDE: http://www.xdecouple.com

Interested in DevOps? Try Flux with XP practices

Posted on by

Culture, movement or practice whatever you call it, DevOps is beautiful. It ensures the collaboration and communication of software professionals who usually doesn’t think alike in most organisations – the Development team and the Operations team. DevOps practices advocates automation of the process of software delivery and infrastructure changes to align these two. Scalability, security and organised chaos promotes a distributed decision making culture, exactly what we need for being agile.

So which framework best suits us, while adopting this DevOps culture? In my biased opinion I feel it’s eXtreme Programming (XP). It’s brilliant practices/ideas are often borrowed by other frameworks including the concept of “User Stories”. Since most frameworks doesn’t specify these practices, most professionals include XP principles (e.g. TDD, pair programming) anyway. Reason why XP, as a methodology, is underrated and overshadowed by other popular frameworks quite heavily.

Flux framework compliments XP, by adding the concept of decoupled processes and making sure DevOps adoption doesn’t stay just a great idea but is also implemented to save the world 😉

Individuals and interactions OVER processes and tools

“Over” is often read as “Not” by a majority of Agile adopters, who finally starts to realise why agility is far better than many traditional techniques. Is it their mistake? Of course not. Agile Manifesto is quite philosophical and the inclusion of “over” just assumes that the reader won’t translate it to suit their needs. It’s either this or that, not both. If both then to what extent? No one have a definite answer, as it was meant to help evolution which is the beauty of the agile manifesto. But it does scare the organisation trying to transition as not all organisations are consultancies. Not everyone is working for a “client”. Sometimes stability is more important to measure few aspects of the transition. This stability and standardisation of processes is necessary to some extent, as long as it’s not blocking the product development.

No doubt, Individuals and Interactions are important, but it can’t work on it’s own without processes and practices to support the outcome. We need a basic level of standardised processes and practices to accompany this vision of adopting devops to become agile. In fact, most frameworks have vague undocumented processes which are not standardised for all teams. It is extremely unsettling for organisations who are paranoid to begin with. If documented, they are extremely ambiguous, hence often misinterpreted (ref. 1, 2, 3).

XDE complimenting XP – Closing the gaps

I have never seen XP work within immature teams because it needs a sense of responsibility and the urge to know WHY, which only comes from experience. If we ask an immature team to follow XP, they usually try Scrum instead and include TDD and pair programming to call it XP. Mostly because Scrum has a guide which they can refer back to. But there are some subtle differences between XP and Scrum, as documented by Mike Cohn.

When we realise most frameworks are ambiguous about implementing set processes, we often fill in the gaps to support the agile principles ourselves. But during this we may end up in a process which can do more harm than good. By leaving a gap we are letting our mind wander. Most professionals look for the processes first and then learn the principles behind it. Some never care to learn the principles at all, as they assume implementing a framework takes care of everything.

This blind faith and incomplete knowledge promotes half baked assumption of knowing what works and what doesn’t. First we should go by book and then we should focus on mastering it or even bending the rules. XDE tries to close these gaps by formalising the Definition of Done and support to DevOps mindset while advocating the best practices from XP.

Companies trying to adopt DevOps needs a framework which have a set of processes for all teams; is predictable yet highly customisable.

XDE provides that skeleton by defining the start and end of the development lifecycle within the bubble. “Done” for a product increment is defined to include End user feedback – Continuous Delivery plus at least some feedback from users before starting the next work item. It creates a transparent environment of keeping the road map visible at all time by focusing on the value to the end user.

To assure that the Bubble doesn’t start working on the next item in the backlog, XDE introduces One Rule (1R) which creates a process of working on one at a time and only focus on outcome not output.

One Rule (1R) makes sure we are focused on Outcome not Output.

Decouple Processes and Succeed

As we know XDE doesn’t proposes any practices on how the product is built but it recommends XP principles. XP principles with it’s test first approach suits the best but needs a robust stabilising skeleton which XDE provides – hence compliments each other. While the 1R team members work following the One Rule, if a team member is free doing nothing (as they are not allowed to work on anything else) they have no choice but to focus on the ongoing work.

  • “Are you free? Great, get the chair and let’s pair for the rest of the day.”
  • “Yoda is off sick today and we need to review the unit tests before he can start implementing the code tomorrow. Can you do it while you wait?”

Therefore, XDE helps organisation to adopt devops mindset smoothly with the least friction possible and XP assures that the quality of the delivery is spot on and ready for feedback. Try XDE along with XP to initiate the DevOps mindset and help your organisation is agile transformation. Focus on outcome not output.

Agile Transformation – Does it have to be Disruptive?

Posted on by

Agile transformation is the new “thing”, most software delivery businesses are trying to get a grip on. There’s a divide in opinion, facts and politics around it. Many running after the “credit” they get in changing a thing or two to get their names in the list of contributors, which may be soon converted into a tombstone. Others are combining the best practices, changing processes overnight and rebuilding culture to support the sudden changes. Everyone wants a piece of the action but the grave consequences are affecting the business they represent. Why? Because everyone expects it to happen faster, disruptive and trying to change things overnight which wasn’t changed for decades.

Unfortunately the message delivered to them reads like this – “Move into agile methods and you can get more products delivered in the same time”.

 

The most underrated fact around these, when we talk about “Agile” is –

“Agile methods will not double your productivity, in fact it will slow you down to begin with. Agile principles are about providing the sense of creating the most valuable product first.”

The above fact is ignored a lot of time and rouge consultants starts selling “Agile” promising more productivity in compared to Waterfall. Terms get thrown from all sides to the person responsible for budget and a chain of middle management roles wait patiently to get a cut. Members who are not supporting the “movement” either receives a calendar invite from HR or get clinically radicalised to the new religion “Agile”. Why are we trying to do Agile? No idea.

Disruption = Difference in Opinion

 

.If this difference in opinion is not resolved, you can never become agile as it depends on the organisation maturity in every aspect. Reason why many of us heard the phrase “Culture change” thrown at us during an agile transformation. A new bread of management leads the bandwagon towards a belief that doing agile will resolve all problems, improve output and finish project early. But here’s a subtle difference which establishes the Value to the business –

Output ≠ Outcome

 

Outcome may or may not be an intended feature, it can be a lesson which we learn from a failure in an iteration. Some might wonder – “What’s the value of this lesson from a failure which is not generating any revenue?” Well, as an example, a failure can teach us how ridiculous a feature is to begin with, so we don’t invest in future iterations of the feature. Hence reducing the risk of creating a worthless product based on the failed iteration which can be a short term success and a long term burden for a business.

Agile transformation, hence, should reflect a sense of purpose of what we are doing and WHY we have to do it. If, as an organisation we are unable to share the big picture to all employees, there is no way we can be agile in a distant future. Agility is not about implementing a framework or method or tool in place and hope for the best. It’s about self evaluation as a company to learn what we can or cannot do, accepting the limits and exposing the barriers which stops us from being agile. We execute, learn and improve.

The best agile transformations are gradual, slow and have a good amount of time invested in learning while we try to move away from the traditional approaches.

On the Contrary, there are exceptions where Disruption is the Only way!

Gradual improvements are welcome where there is no need for drastic change. But in some organisations this empathetic mindset can be taken for granted. We will find personalities who are extremely qualified and have a very good knowledge of what is right. But milking it seems a better idea for them rather than improvements while exploiting the same knowledge of agile transformation. This is especially true if they are not a “Permy”, as their political existence is based on how long they can stretch the project to get maximum benefit out of a contract/temporary role.

I would be wrong, if I say all contractors are like this. Of course not. In fact, most team level contractors are exceptionally brilliant and embrace agility. The issue starts when we have the middle management as a contractor, who can influence crucial business decisions. These personalities will not harm the business but won’t improve it either. They will keep it as it is and in the name of “Agile Transformation” the project can last for years to come.

Agile Transformation doesn’t happen in a quarter, but it shouldn’t take over a year either.

 

If it takes more than a year with low or no relevant value delivered, we can be dead sure that it is being prevented by a crucial impediment, a process or a personality on power. It can be anything. A year long transformation should be a warning that, not everyone is on board. In these situations, empathy should be shown to personalities who are on board and the rest should be disrupted to make a crucial business decision.

Do you feel the same way?

Which version of the transformation have you experienced/experiencing? Would love to hear your thoughts on this.

Consider SHU over HA and RI

Posted on by

We come across many ways to become agile in our organisations, to name a few ways – Scrum, Kanban, XP, XDE and more. We want to become agile by being reactive rather than proactive, so that we can embrace change. We want to provide value, that is the goal. Being agile is one of the means to achieve that goal, not a goal in itself. Same goes for lean approaches which tries to reduce waste, a mean to provide value, the goal. Therefore, “elders” in this context are “scared and healed” thought leaders rather than traditional mindset driven older generation.

 

So why suddenly elders need respect? Aren’t we respecting them already? Hard to say really, as many of us say we do but may not really mean it, unconsciously. Even educated professionals may think they do but they don’t as they are too busy reinventing the wheel either because their training was not up to the mark or they are returning a favour to an old pal. I heard someone saying the other day – “My friend told me that Scrum slows them down, so we tried Kanban instead which turned out to be a disaster.. agile sucks in general anyway”. You know instantly, they have never understood the values and principles, so forget about the events and activities which binds it together.

Reason why, among traditionally trained professionals we hear so many discussions like – “Scrum is terrible“, “Kanban is the new Scrum” and “XP sounds like exactly the wrong way to go” and many more. Community members who say these, may have never seen it working in the first place OR don’t want to improve OR have seen a bad implementation which focused on goals like “Agile” or “Lean” – they may not realise that the goal is to “Deliver Value” and agile/lean helps you provide the value but not THE goal to show off.

 

So what any of these have to do with “Respecting Elders”? Well, the above is exactly what you get when you don’t respect the work the founders/creators aka the elders have carried out, number of times they have failed (learned) and amount of sweat they wiped in their lifetime. Most of us don’t spend time actually implementing a method “by book” in the first place. Learning curve is a waste for them and don’t even get me started on how some likes to bend the rules while calling it a “Flavour” of XYZ. This reminds me of a very interesting quote –

Those who do not want to imitate anything, produce nothing ~Salvador Dalì

 

We need to get into the mindset of learning, mastering and transcending. Yes, I am talking about ShuHaRi. I bet a lot of us may have heard about it, if not you have a link now. Shu is where you imitate without worrying about why you are doing it. Trust the research which has been done for years (some more than your age) and atleast give it a chance.

20 years experience in traditional techniques, does not make you an elder in mordern approaches – unless you have invented/created a better approach !

 

True elders have spent almost all of their professional life creating the agile/lean principles and practices, if you will. Then “By Book” should be your baseline, unless how can you criticise something you know nothing about? Once you know what by book means, then you can ask yourself if this is the right approach for your organisation or not. Nothing is a silver bullet but these are atleast “a” bullet to hit your targets, from which you gain experience and modify accordingly.

 

Some Examples of unintended disrespect:

“We have introduced Scrum before and hired a Scrum Master. He ended us hiring a Product Owner who replcaed our BA who was sufficient enough and much more cost effective. The team’s output slowed down since and 1 month later we realised we don’t want Scrum.”

“We have an electronic Kanban board where most of the items are blocked so we started to work on new items. The testers are uselessly slow and we ended up with nearly 20 items in testing swimlane. The developers were awesome though, they worked on all items in time but were kept getting blocked by the testers.”

“We tried TDD and wasted much of our time testing before writing the code while pair programming. We ended up with 90% test coverage but a plethora of defects which should have been caught by Unit tests during CI. So, we are now concentrating more on automated selenium tests after development.”

“We don’t need retrospectives as we never get where it adds value. What’s the point of revisiting past when we can use the time to concentrate on future?”

“In our Kanban board, we have a WIP limit 4 but we change it every week according to our need. Kanban says we can change the WIP limit anytime, as long as we visualise the workflow.”

“Our product owner needs to write user stories in Given/When/Then unless I have no idea what he asks me to build. He needs coaching so we developers can do our job faster. I think working as a Scrum Master alongside is taking a lot of his time.”

“BDD is just a language defining the behaviour and nothing else. Stories should be in BDD unless it is not Scrum, correct me if I am wrong.” (P.S: He did get corrected with a mandatory day long BDD workshop, he asked for it.)

“We need all the daily scrums happening between 9 till 10am, for all our teams. The project manager is only free during that window.”

 

You get the picture. These are very few examples among a million out there (Feel free to add more examples on comments). The elders are never mentioned but their experiences are challenged and disrespected everytime someone use these phrases in any format. Lack of knowledge is to blame or is it?

Respect these elders, we don’t need to fail the same way they did and learned. We have the wheel, we just have to use it and keep applying the WD40 (common sense) when required.