Tag Archives: Lean

WWWA – #2 Harsh critics of Agile or Waterfall (or Bacon) are Awful Researchers

Posted on by

WWWA = What’s Wrong With Agile

I know, I said it will be weekly. As it turned out, I actually prefer responding to change over following a plan. A quick recap to the goal of this series, which will stay same on every following article – to make some space in our brain for this to stay in:

 

#1 – Agile is widespread, the Agile Manifesto isn’t

#2 – Harsh critics of Waterfall or Agile (or Bacon) are Awful Researchers

Criticism with opinions is a no-brainer. Although, Criticism with facts require investment of quality time, uncomfortable debates leading to self assessment and the will to learn from the one being criticised by us. In this article, I will take a U-turn to explain a misconception which many of us don’t know exists. We have other follow up articles to get back the respect Agile needs but we have only this article to finally respect “Waterfall” or what it stands for. As always, keep an open mind.

Overly Favourable Views

“People tend to hold overly favorable views of their abilities in many social and intellectual domains… …this overestimation occurs, in part, because people who are unskilled in these domains suffer a dual burden… …people reach erroneous conclusions and make unfortunate choices, but their incompetence robs them of the metacognitive ability to realize it.”

Highlight of the abstract of a published whitepaper – the basis of a Nobel awarded (for Psychology) to David Dunning and Justin Kruger.

This is true for both Agile admirers and haters. Both are guilty to some extent. I was too, certain years back. With no actual working experience of “Waterfall” and what it involves, it didn’t made sense to me and simply hated it to the core. Statements were made which were heavily biased towards Agile/Lean.

Then, almost like a Karma (if you believe in that shit), I had to work in a Waterfall project! It was really awkward to realise what was wrong. With an Agile goggle on it was my approach that needed an upgrade, I wasn’t listening to the so called old mindsets.

“Trust me, if we could we would. The amount of dependency and politics we deal with, be thankful it’s not taking a year” – whispered a devil’s advocate.

 

Being used to the XP practices, it took me a while to digest and understand. I kept working in their sluggish pace to provide a value in a quarterly basis which was better than it used to be. Soon it was clear why agility makes sense and thankfully found the mojo back to move on with the experience. It wasn’t the mindset, it was simply the organisation we were dealing with. It made me come to this conclusion –

Mini-waterfalls within a fake sprint on a No-Scrum, sometimes still work. That’s the most we can get out of from certain organisations.

Not ideal but not the worst possible outcome. Now I can say, the traditional mindset/techniques (not specifically Waterfall – more in a moment) lacks the solution to provide values when we need it in today’s world, although don’t hate it anymore.

A brief history lesson to the Waterfall haters

You are about to be amazed if you haven’t really gone deeper into the subject of what Waterfall stands for and why you should – for a moment – take your Agile goggles off to read this.

The term “Waterfall” was an accident. A mere resemblance between a flow diagram and a waterfall. It was originally drawn to explain an iterative and incremental approach.

 

Yeah, you read that right – “an iterative and incremental approach”. One of the pioneer’s of the software development industry Winston W. Royce one day decided to write a paper on 1970 to express his “personal views about managing large software developments” while calling it “Managing the development of large software systems” – without a single mention of “Waterfall”. He managed to draw some visuals expressing his views, one of which is this:

 

Royce advocated that, projects should pass through this at least twice. That’s an iteration described right there, although not perfect for our current world but good enough for the world then. Bell, Thomas E., and T. A. Thayer on 1976 then published their paper on “Software requirements: Are they really a problem?” and coined the term “waterfall” referencing Royce’s article – managed to do the permanent damage, unintentionally.

 

We know the rest. That analogy turned into a topic of mindless criticism which was simply about “an iterative and incremental approach”. In a way, therefore, the concept of “Agile” has evolved from “Waterfall”. I hear you mumbling something, please don’t hate the messenger.

So, the term did more harm than good and may be that’s where “Agile” is heading which we can stop. “Waterfall” has become a word which is now spoken with a guilt; usually an enormous amount of shame is associated with it. Ehm.. “people who are unskilled in these domains suffer a dual burden”. I rest my case.

 

Sounded like a Waterfall lover there didn’t I? Truth is Waterfall (or whatever you like to call it) is still used widely although Agile is the better among the two. Just make sure we understand both before we criticise any of them. Better, just leave the debate behind, it’s not worth it. Respect both, embrace the one that suits you at that moment of time. Be loyal to the one you favour and explore yourself if you can improve.

Technically Waterfall was 20 years old when Scrum was born (1996) which is the most widely used Agile Framework. It’s been over 20 years to that as well.. you never know what’s in the corner waiting to emerge for us. Most probably another framework which offers even more faster feedback 😉

P.S: You may have gathered, this article had nothing to do with Bacon. Although it was about the Beacon.

WWWA – #1 Agile is widespread the Manifesto isn’t

Posted on by

WWWA = What’s Wrong With Agile

Welcome “Agile” admirers, haters and the lucky bunch who are still unaware hence unbiased readers. Glad to see a controversial article header gained your attention. It is not a click bait though and may be oddly unsettling to the admirers and haters specifically as you read on. It’s not good news unless we act on them and we need both parties to calm down for a moment, shake hands and stop bitching around.

Recently, I was accused of being an Idealist (no idea why it’s a bad thing) and living in a world of illusion. Pretty sure most Agile Coaches are branded as idealists if they are doing enough effort to highlight constant improvements. Apparently the myth called “Agile” only work in dreams. My reaction to this was rather cold though. Mostly because, there are times I do feel that myself. Not because it doesn’t work but because the perception of what Agile is, is still not clear to a majority of development professionals.

This article is the first of many on a series of articles which will be published every week (following a plan over responding to change.. Can I dare?). Here’s an effort to clarify what really is wrong with the interpretation of what Agile stands for today.

#1 – Agile is widespread the Agile Manifesto isn’t..

Leave the 12 principles aside for a moment, at random just ask for the 4 manifesto statements to a person selling the brand Agile on their product/services. If you can find confident 4 statements in any possible variation, ask how many of them they have managed to use or will be using in the workplace. If the person have taken the effort to memorise the 4 statements, they will probably be honest enough to tell you the truth.

Most of us cannot follow one or another or any of them in our workplace, for various reasons. That’s when we take a moment and question, is it even possible? We are busy doing “hard work”, who has the time for all these? Working the way we are expected to – pays, being an idealist continuous improvement seeker human – will probably get us fired.

Agile principles and values - Google Chrome 2017-06-16 11.41.11

Source: https://www.slideshare.net/TroyLCSMCSPO/agile-principles-and-values-62447757

 

My faith was restored when I saw it working once, only that one time – the company was being agile (a very good one) and had the manifesto and 12 principles bloody engraved in their memory and on the walls of the office. Also, they never used the A-word as a unspoken sacred rule.

Sad that the Agile Manifesto is not widespread like the actual term Agile. May be because it’s written in English which most of the world doesn’t speak/understand.. hang on. It’s impossible to memorise those 4 statements that holds the truth but it’s easier to memorise all answers of the multiple choice questionnaire to get the certification done. It increases our day rate, isn’t it?

Back to basics – a quick recap:

Here’s an unbiased pro-tip:

You can always be more agile, it’s relative.

Providing “fast feedback” depends on what is “fast” to you.

For some it’s a month or a week and for some it’s a day (stop showing off you!). There’s always will be a better version of ourself. Large organisation can be agile too, it just simply won’t be agile enough to call it that and to some it will be a #NoAgileBanter 😉

So, next time you hear someone throwing “Agile” at you and in a mood for trolling or simply like to be a dick, just ask. Just make sure you know it to begin with. Best place to ask is job interviews, if you care. The candidates have no choice but to answer or carry a risk of losing the opportunity. At least you will educate them and make an effort to spread the word directly.

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

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.

Annual Budgets – Silent killer of Innovation

Posted on by

Large non-IT enterprises are using software development as their supporting delivery strategy which forms a part of their business, but not for the sole purpose of business. They mostly assign a yearly budget on any project to increase predictability.  They tend to keep the expenditure controlled along with a buffer using some validated numbers collected from last financial year. This is a trend adopted from the “manual labour” culture where we can predict expenditure in advance. But it doesn’t work when a work depends on our thought process, experiments and fast fail approaches used in software development we use today.

 

In manufacturing, budget can be controlled and improved by lean mindset as it becomes predictable. Similarly applying an agile mindset on development works like a charm. Although, the non-IT businesses fail to see the difference between a development line and a production line. This is the biggest impediment which affects many organisations today as it can be completely ignored in many cases.

Yearly budget is the silent killer of innovation and encourages bureaucratic culture in software development.

 

Many of us have come across this impediment, if we are working in such an industry. We should decouple the budget to be flexible and get support when needed without abusing the freedom. This increases the transparency around the budget expenditure which can be verified after the financial year rather than predicted before a financial year begins. We can never know how a business shapes itself in coming months when you have multiple competitors to worry about.

Decoupling the financial budget creates a “Pull” instead of “Push” mindset.

 

Decoupling the Budget process

Let’s take XDE Framework as an example. This proposes “decoupling” of all processes to achieve the best possible solution in given time, focusing on independent and futuristic business model. XDE requires us to form a temporary “Bubble” by combining specialist team members from 2 types of permanent teams, One Rule (1R) team and Product Team. This bubble can be dissolved when a planned work iteration is shipped and is successful.

Coming back to budget, as a process and an impediment. 1R team (or any team) can suddenly realise while in a bubble, that they need another technical expert to get through a planned work. Do we want them to wait and check if they have enough budget for that? No, we authorise it providing they have a sensible reason on why they need it in the first place (common sense). Dissolving a bubble is not the goal; it only encourages us to plan well before the bubble is formed.

 

Don’t hold the development teams responsible

We shouldn’t hold the teams responsible for not seeing an unforeseen impediment like the annual budget. We don’t need funds without knowing where we are going to spend it in a year time.

Common sense should prevail.

We need to be agile as an industry, to support the teams analysing the circumstances pragmatically. As we all know, agile mindset helps an organisation best when it comes from top down rather than bottom up.

 

“Pull” reduces Waste

WhatsApp Image 2017-06-15 at 5.46.49 PM

Financial budget is dealt by a specialised Finance team in non-IT organisations. Reason why they assume that software development teams are one of many departments providing a predictable service. This is where the mindset need to change and we need to decouple the financial budget for development. Provide funds when required rather than pushing a set amount in and hope for the best.

We might be spending more in software development than required, so that next year’s budget can stay same or more – that’s Bureaucracy

 

As the development teams are pulling the funds when required, there will always be a valid reason and this increases trust in the culture. This culture will empower the development team members and assure distributed responsibility, rather than hoping they have enough “resource” to cover the work they planned where Finance was never actually involved to begin with.

Does this resonate with your experience working in a non-IT industry? Would love to hear your thoughts around this and will be great to hear your personal experiences. Keep calm and decouple budget for software development !