Annual Budgets – Silent killer of Innovation

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 !


Scrum Events in Layman’s Term

Scrum helps in developing complex products. It is easy to learn but hard to master. Easy to learn, because we have a guide with rules which beginners can refer back to. Hard to master, because just blindly following the events will not get you anywhere. Many teams try to bend the rules without mastering them first, which is why they fail and end up blaming Scrum.


Scrum guide is clear about the events and explains why they exists. Although sometimes it is not sufficient to just point people towards it and assume they will read it. Shared document is not shared understanding. Some may never read it and they are usually after a much simpler explanation on the spot. That’s why during or after implementation of Scrum, we usually hear some basic questions within an organisation and this article explains one of them.

Briefly explain what we do in the Scrum events in layman’s terms?

Here is what you can explain, assuming you are explaining to a layman who have no idea why the development team have selected Scrum. Before going to the events, lets understand some basic terms which makes it easier to explain the events.


Requirement: A “problem”, because the solution doesn’t exist yet. Our aim is to implement the solution.

Epic: A big problem.

Story: A small part of a big problem

Bug: An unknown problem

Scrum Team: The godly creatures with super powers 😉

Now, let’s see how we can explain the Scrum events and activity.

Refinement Activity: Scrum Team try to understand if they have enough information about the variety of problems.

Sprint Planning: Choose the bigger problems and create a strategy on how to implement the solution.

Sprint: Implement the solution without being distracted.

Daily Scrum: Daily check on “Are we on the right track on creating the solution?”

Sprint Review: Understand the solution and verify if it actually make someone’s life easier.

Sprint Retrospective: Have we learned anything new while creating the solution?


That’s it, it’s just common sense redefined. As long as we realise we are solving a problem of variable complexities and use the above thought as a guide, it all make sense. Hope this article can solve someone’s understanding of the events and what we should be doing in them.


Being agile by hiding the Evidence of Agile

Branding has positives and negatives. For agile enthusiasts, it can be a curse especially if we are acting as the transformation agent while using the term “Agile”. If we want to transform a culture from traditional to agile mindset, the last thing we should focus on is the term “Agile” and should keep it inside our post-it satchel. While learning it the hard way, I have effectively used unbranded agility, I call it the “No-Name Agile”. Oops, just branded a technique which probably most agile transformation leaders use.. the Irony.


To market a term, we just need to enclose it in a quote, throw in a slide during a presentation and we are golden – “WE” are golden but the community may not be, who it was originally intended to. From that moment, a golden journey begins for the entrepreneur among us and the phrase is thrown into every event, technique and books around us, adding more and more quirky terms in the dictionary. Therefore, the last thing we need is the term “No-Name Agile” to convey my message to the community in this article. Reason why on the One Rule (1R) Development Framework also known as Xtreme Decoupled process Engineering (XDE), every role is named as less quirky as possible. 1R/XDE Framework focuses, lives and breaths unbranded agility. Unbranded agility, hence, takes over “No-Name Agile” from this point onward.

One might wonder why would we need unbranded agility? Let’s say, we are consulting a company representative who is leading a team working in the traditional way. We believe they might be intrigued to learn about “Agile”. An inexperienced agile transformer will assume the company representative will say something similar to “That’s an interesting new approach, let’s try that !”. That’s the perfect little world right there, everything is sorted. May be it’s just me but unfortunately I have never seen anyone respond with a similar phrase.



An organisation has already been exposed to frameworks which supports theAgile Manifesto, unfortunately in a horrifying way and they may have lost the faith completely in anything that has “Agile” as a suffix or prefix. Here’s one of the real life situations and the most polite conversation I had with someone from such an organisation:

Me: Probably we need a different approach. I have seen something work pretty good in my last workplace, Agile Development. We basically started faster feedback cycle and were able to set a good pace of delivery. Have you ever tried it?

X: Yeah we tried a “flavour” of it last year, it was pointless. The Project Manager ended up spending double budget than originally suggested.

Me: I think the implementation is to blame. As a new member, I can see some very basic concepts are missing among the team members. We should try it by book first and then try to formulate a flavour which suits us later.

X: No offence but Agile is not an answer to everything. Sometimes it just don’t work at all. Scrum wouldn’t work for us. We certified the PM to play the SM role a while back but the velocity kept going down and he didn’t get much time to play that role anyway. We have tried it all in the past year, all was a disaster.

Me: When did I ever mentioned Scrum? It’s one of the ways to be agile, not the only way.

X: Ye ye, Scrum or Agile or something else all are the same; it’s always “green on the other side of the river”.

A failed attempt to be an agile advocate on the second week of work; to suggest something better using the brand “Agile”. What went wrong? Well, I took the same approach and made the same mistake like others who tried and failed before me on this company.

The mistake was in not explaining the principles behind it, first.

There is a reason we have an Agile Manifesto which documents the principles effectively,. Weeks later, I started experimenting unbranded agility and here is the conversation (not verbatim but close enough):

(Context: The development team have build the product wrong as the shared understanding was missing during the implementation.. no feedback cycle.)

X: We need to find out what is happening in that team. It’s affecting all our SLAs, it’s appalling. Why are the developers suddenly saying the requirements were ambiguous when the PM explained it very clearly last quarter and shared it with them. Seems like no one reads their email any more and nodded when asked.

Me: I think we should have added few “official checkpoints” to understand if we were all in the same page. 3 months is too long and I wouldn’t be surprised if they were nodding just because they had to, knowing their line managers were in the same room.

X: What you mean by checkpoint? You mean like a requirement re-visit session every month?

Me: Well, not a requirement revisit as it seems like the stakeholders were assuming it will never change. I meant like a frequent huddle; more frequent, like everyday.

X: Oh.. you mean like a daily stand up with all those 20 developers together? We did it before as you know and it was the only thing I liked about Scrum.

Me: *coughkillmecoughkillmenowcough* Exactly, all 20 together sounds good (..NOT). At least we will know what they are working on every day and we can clear the confusion regularly.

X: Let’s do that, I will speak to the PM. Let’s see if it works out in the next quarter.


Phew.. right there, a small win in the very beginning of a year long unbranded agile transition plan. At least a stand up was finalised, I ignored the “all 20 together” fallacy to raise hell by itself. Soon the organisation realised that we were wasting time on a hour long stand up and voted for shorter feature focused stand ups. We were so happy to see a “brand new” approach and only 15mins time-boxed “digest”. Following that conversation, I have started gathering the following terms and still use them for key discussions during a transition:

And so on… This list can re-use so many known terms and we need the community to help us collect them all !

Sometimes, the resistance towards a branded term is not always professional, it is personal.

Some management entities may never like the way Agile Manifesto focuses on collaboration and try to (indirectly) advocate empowerment, removing most middle management or convert them. Self-organisation and Self-managing teams sounds extremely fishy and sometimes a load of horse faeces to traditional mindset.

If someone has spent majority of their career to be where they are now and did things they are proud of, they will not screw it up just before their retirement.  Let say, if I was a Project Manager with an MBA, PMP certified (or similar/more) and have 10-20 years plus of experience, do you really think I will sacrifice it all easily? Good luck with that.

Many will agree that a majority of traditional management persona are often very insecure and extremely reluctant to change and transform to agile values. They will resist everything which can burn their position of “Command and Control” down to a Servant Leadership. Down – because they think it is below their current status, to be a servant of a team they micromanage now. Only way you can get through to them is with compassion and assuming that they may never change for that moment of time.


Not everyone among the traditional Project Managers are resistant though. Many of my close friends who used to work as PM have realised it on their own and happily changed their ways of thinking. Unfortunately, their employer will not change the job title so easily, it gets much more complicated. Point is, we shouldn’t force them; rather, communicate with them through the principles.

When the “Role” becomes insignificant without losing any employee benefit and they are being agile while producing desired value, please leave them alone.

You got what you wanted as an Agile Transformer. Our goal is to make it happen and as long as we know we have done it, just get a chilled beer and celebrate. We just have to make sure what we have helped establish is a stable and sustainable culture and doesn’t fall apart.

Unbranded agility, helps us to implement agile mindset without making it a bigger deal.

Agility is common sense which we usually forget to remind while explaining. What we need is a good amount of patience, focus and integrity sometimes without getting any appreciation at all. The professional satisfaction we gain is much more valuable than taking the credit for a change which we can do another 100 times if given an opportunity.


Let’s collect & re-use:

The table above is to give us a simple example which one agilist alone can’t/shouldn’t create. It’s intended for the community and community have to build it together.

Let’s unbrand “Agile” for the sake of making someone agile.

Please send all your suggestions on comments or private messages. They will be collected in one place, shared while crediting the contributor. Hope to hear from you soon.


Defining Done – The Holy Cow Approach

While reading Invest on an Epic Story and get the job Done, there was a discussion about how the done checklist can be formulated with mandatory and optional sub-tasks. This article can be considered as the prequel which forms the basis of that implementation. A question we always come across while explaining how to define Done for a Story is –


What is “Done” or “Done Done”? How much is enough?


Truth is, it can be done or done done or done done done or (done)n. Done can mean a hundred different things for a story completion within a product backlog or within a team or for the consumers. The definition lies on the “baseline done” which everyone agreed to, before the work commence and the team takes it seriously as a discipline. The goal of this article is to get back to basics about defining Done for your story, I call it the “Holy Cow Approach”. This drives the thought process around “Done” and how you can resonate with a real life example.

Steaks.. we all love steaks (apologies to vegetarians). But we like it done according to our need. We do get annoyed if it’s not the right cut, colour, texture, seasoning or even the way it is presented.


Now, assume I am the diner and have made it very clear while ordering that I wanted it “Medium Rare”. That does it for me, that’s the minimal requirement (MVP). When the steak finally arrived, it turned out to be Medium.

How dare they?!

Dissatisfied with the outcome even though giving the correct requirement (I hope), as a furious consumer I have sent it back. My fellow diners sitting next to me ordered a rare (what an animal) and a well done (c’mon, it ain’t a burger). They did get their steak as they like, on time and were fully satisfied with the service and left a great feedback for the chef. That’s ⅔ aka 66.67% happiness rating.

So what went wrong? There were many possibilities of things that could have gone wrong, to name a few –

  1. I might have said Medium and never said Medium Rare.. oops my bad. (Consumer)
  2. Waiting staff might have missed it and wrote the wrong order (PO)
  3. Head Chef might have vaguely communicated it (Dev team member)
  4. Sous Chef kept it a little longer on the grill (Dev team member)
  5. No one bothered checking if it was actually medium rare before serving (Inspection)


If we leave the point-1 aside (as wrong requirement), the rest depends on the team who delivered and is responsible, even if any one member missed a step before serving. May be the team should have considered it a part of the quality. Basically, what I have considered as Done as a consumer, wasn’t the definition the team knew or misinterpreted or was a human error. To them, say point-5 was the issue, 5 wasn’t really part of their Definition of Done (DoD).

Let’s compare this directly with a product team who have a similar pattern in defining done which doesn’t really align with what consumer asked for. If multiple teams are dependent on each other but defining Done differently, can we trust the process? Yes we can, if it’s a common knowledge and have been made explicit.

Forget about the consumer and interdependent teams for a moment. Consider a Product Owner (PO) and the Development team, who has completely different level of understanding about what is done. PO wants a demo of the finished iteration but the “development” team is divided between programmers and testers (reality of many teams). So they tend to assign done on their work to throw it over the fence – Programming Done and QA Done. Even after all this, the “finished” product is sometimes useless as the environment dependency wasn’t considered as a factor at any point of the “development”. These are all part of the mandatory definition of done as a common practice and basics of what we do as a team.


Back to the Holy Cow again. So the restaurant kitchen considers serving the food on the table as done. For the Restaurant owner it is NOT Done. It is done for the owner when the consumers pay and leave a good feedback. For the consumers, it is none of those. Consumers only care about getting the “Dinner” done and get the worth of their money.

Now, If we assume Scrum is being used as the framework and compare the roles to visualise the definitions:


Done for the Kitchen (Development Team):

  1. Order received and picked up by the head Chef
  2. Head Chef reads the order and asks one of the Sous chefs to pick it up or started working on it himself/herself.
  3. The Chef takes a nice 8oz cut (requirement ignored for simplicity of this discussion) and starts grilling it
  4. Chef thinks it’s done as per the order
  5. Head Chef calls for the waiting staff to take it out to the table


Done for Restaurant owner (SteakHolders.. Oh wait.. Stakeholders):

  1. Consumers arrive, approached and seated as quickly as possible
  2. Consumer orders food
  3. Kitchen cooks and food is delivered on the table
  4. Consumers cherish the food
  5. Consumer paid, left a positive feedback and the table is rotated


Done for Consumer (Clients/Users/Customers):

  1. Find a nice steak house
  2. Arrive as planned with mates to cherish a moment
  3. Steaks ordered
  4. Drinks while waiting it to arrive
  5. Steak arrives
  6. Yum.. Om Nom Nom..
  7. Pay and leave for the late night party or some prefer it the other way shown.


Examples above highlights a very simple behaviour we have seen, depending on who we are at that moment of time. No one is on sync and why should they, everyone has their own life. We just need to take it into consideration. We need to cooperate and work together so everyone is satisfied; especially the care should be taken from the provider side as they are responsible for the successful delivery to the consumers. That is their business and source of revenue.


What’s next?

Stating the obvious but it’s time to take DoD seriously if we aren’t already. Apply it to all work items. If we don’t know the goal we can never achieve it. It is ofcourse negotiable so take the opportunity to discuss, establish and share the common knowledge without bypassing the key personas – the PO or Stakeholders or the Consumers.


Rules of Thumb:

  • DoD should be made explicit as a discipline
  • DoD should be negotiable but a baseline is very important to start with
  • DoD should be established pragmatically and cannot be same for all stories
  • Without a baseline DoD the product team should not even start working on the story
  • DoD is essentially a checklist and should be treated like one at all times. It can change as we learn more about the story implementation.


P.S. Religiously, I like my steak Medium Rare and I will snap if I get served a Medium. That’s my DoD. Get in touch if you want to take this discussion further in a nice Steak House around you 🙂