Tag Archives: Scrum

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

Scrum Events in Layman’s Term

Posted on by

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.

Defining Done – The Holy Cow Approach

Posted on by

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 🙂

Is Agile Mindset Adoption is a Mission Impossible?

Posted on by

First of all, this isn’t another post about how to be “a”gile and not do “A”gile. Neither it is about if Scrum is better than Kanban or XP. This post is all about the psychology behind the raw nature of human tendencies, it’s about professionals working in IT  and having a simple question about why moving from Waterfall to Agile Mindset is often a tedious task and shockingly tough even though we know it improves productivity.

 

Let’s start with few ludicrous questions (or are they?). When you answer them hopefully I can stir up your thoughts and by the end of this post you may realise what I am talking about.

Are you Selfish?

Are you a Hypocrite?

Do you lie?

If you said “Yes” to all these questions then please read on. If you said “No” then that’s just a confirmation that you do lie, even to yourself (so keep reading !).

Being said that, the writer of this post is fearlessly accusing you of being a liar, hypocrite and selfish – what’s his answer?

Honestly – YES to All !!

 

Because, I am a human not an Alien or a Robot or a Furniture. It’s the obvious human thing to do/be. We can get millions of examples like that in any country, any religion, any race and many events of our personal lives. Let’s move back into the topic though and do something what you might have done during your nursery sessions as the cutest kid, according to your mum. Repeat this sentence twice in your head –

To some extent every human lie, act selfish and of course is a hypocrite by Nature !

Offended yet? No? Then you, my friend, understand what Agility means in Software Development. Yes, I am referring to those 4 Manifesto for Agile Software development and 12 Principles Behind Agile Manifesto. You are a frank, confident person who loves improving and Accept the truth – that’s how you improve.

 

Talking about Mission Impossible – I was referring to the Tom Cruise starer epic action movie series – love all of em. The “Mission” always feel impossible but somehow it gets sorted, often sacrificing one of a lead character and we see a happy ending overall. But here is a truth we all know, we as professionals know that professional life is cruel, misguided at times and not really a happy ending instead is just a constant struggle to achieve better than the last time.

 

Agile Mindset Adoption – is that Mission which is somewhat Impossible. The culprit is that “Being Human” nature and sadly we do come back to that basic nature quite often. The art is to quickly realise that you are falling back. Agile mindset teaches us that control.

What Agile principles teaches us is to NOT be Selfish, Hypocrite or a Liar – bloody opposite to human’s basic instinct.

Knowing that we humans are never 100% certain about our behaviour all the time, we are bound to fall back at times and sabotage agility for our own need. That can be for anything starting from getting a lazy day off, love for the code you write, sheer dedication towards the spreadsheet that you just made from scratch or just loving that fact that you are the Boss. This is the very reason we don’t want to be Agile in personal life.. at least I don’t. It feels restrictive, not fun and often unnatural.. which it is.

 

Now that we established we cannot get around it (correct me if I am wrong), the best thing we can do is to control them in professional life as much as we can. To become a successful company, all employees needs to be co-operative, adaptable, organised and communicate clearly, listen carefully and respect customers. The more you go against your human instinct.. the more successful you be as a professional. This will reassure the fact that you can’t stop it but you CAN control it for the sake of the business.

AAEAAQAAAAAAAAXrAAAAJDhhNjk2Y2MyLWE3MzEtNDgyZi1iNGQxLTA2ZmMxZGRhMmMyZA

Improvement Examples

Scenario #1 : I am a developer who have 100 awesome ideas.

Road to Disaster – Although great, none of them has a real benefit to the company I work for. I am selfish so I will pitch for it, screw others it’s my area of expertise. I love thinking Lean but for this one time lets be a hypocrite and lie about the real value.

Road to Success – They are great but can’t see the value for the product. Let’s work on them on my personal time in place of the regular gaming session. If I find a connection which “solves a problem” I can pitch for it then.

 

Scenario #2: I am a developer who worked my arse of for a feature, which has to be rebuilt on client request

Road to Disaster – Although I know it is right, I would rather be a hypocrite, make an issue about it saying how upset I am, how it is not right as the requirements should be spot on in the first place. Name and blame Scrum or just Agile in general as it’s asking me to throw out my beautiful work.

Road to Success – Think Lean and ask why. Get a clear reasoning and get to it. Person who changed the requirement most probably know more than you about the market research or client request and they also must have considered the consequences. This may potentially overcome those and create more value. Embrace change very late while being agile (I invented that line.. stop laughing.. I did).

 

Scenario #3: I am a Boss (any kind) and believes that I can control development by pressurising

Road to Disaster – I have told to get the Feature X done in a Quarter. It can be done and I kind of don’t give a shit (selfish) what the estimates are as I have already given my words to the partners that it will be done (lie). They are giving us Millions for it so we have to hire more people instantly to get it ready quickly as we know 10 women can deliver 1 baby in 1 month (hypocrite).

Road to Success – I have “asked” the Development teams if we can do the Feature X done in a Quarter, before I give a “sane and realistic” date to the clients. We found out that around 70% is possible in the time frame which can produce a working iterations with all functionality but may have bugs. Clients are adamant that they need it polished with no bugs, in any cost or loose the deal.

 

I can do one of these or a combination of few –

  1. Get help from an agency to work on side with established Agile practices for the extra work “without” hiring new people.
  2. Tell the truth to keep it clean and save reputation. Clients are demanding sometimes not stupid. They are humans too and most humans have one thing in common.. common sense. They will respect you more for telling truth.
  3. Communicate every action clearly and show that you care. Developers will respect you more as they can feel your pain.
  4. Pressuring the way towards an impractical deadline (the decade old mentality) will only push it back and you will end up with 5 unfinished products rather than one strong “valuable” product.
  5. Fight your human instinct if you know you can control it.

 

That’s all folks !

Meetings – It’s all about planning the Interruptions

Posted on by

!

First thing you will notice while reading this post is the image above. Today at this very moment, when I searched it in google (noticed the new logo?), I could see the most searched phrases as above.. WOW !! It’s quite common to see someone saying “Meetings are such a waste of time” or “Meetings interrupt my work rather than solve the problem”. I bet you heard this before, at least once in your professional life or even felt like that.

 

Yes, I freaking hated meetings as well, as it never helped me (6 years ago). Sitting together with a bunch of hot shots who mostly try to put their opinions forward and try to route the decisions to their own liking. I used to like the fact that, if I get a call in between, I can finally say “Can I call you back? I am in a meeting right now !” Being a recent graduate these things were in my “Things To Do” list as a ‘Professional’ 😉

I was wrong as you might have already guessed, mostly because I never understood why I was in that meeting room. I only attended just because someone invited me. Realising that I loved the attention when I had something to contribute, whether it meant anything or not, I started regularly attending the meetings and my productivity started going out the window.

So, I did some basic self evaluation as this wasn’t the experience I wanted the achieve during my graduations. Anyway, 5 years ago when I was somewhat serious in my career, I read few blog posts and professional opinions about Meetings in general. Most mentioned that meetings are always a controversial topic for sometime and a successful meeting is widely dependent on the organisers ability to achieve something. Months later, co-incidentally I was introduced to Agile development which changed my views forever, for good.

This post about Meetings is not about Agile though but Meetings in general. In these 5 years, here is what I learned about it and ways to make use of some basic concepts.

 

Ask yourself: Do you have a ‘Goal’ to reach after this meeting?

That’s a simple question so just answer it to yourself first. If not satisfied with your own answer, ask the organiser. You may find them acting all rad about it and even a little annoyed. Your answer – “I am sure you have your reasons but does it have to involve me?” Let them think and answer to that question. It will simply rectify any confusion right away. You will get an answer on yes or no, simply explaining why. There won’t be a grey line if they are 100% sure.

Benefit – You know why are you attending the meeting and what will be your contributions to it.

 

Ask the members: Is this the Goal we are trying to discuss?

Yes it is, unless they wouldn’t be joining it. So where’s the ‘controversy’ coming from? Well, the moment we start discussing a topic which slowly takes another road, which seemed important at the time and ended up discussing nothing, especially the original topic. Who is responsible? – All of us involved in the meeting. It’s like watching a crime and not reporting it which is actually a crime too.

How do we cope with it? Be the hard nut and “Raise Hand” interrupt everyone discussing the topic which is diverted from the original. People may look at you like you are a maniac but you will save your valuable time as well as their’s. Politely say that you think this conversation is not in the scope of the current meeting and should be discussed separately; if really necessary to be kept short.

 

Meeting are interrupting if it is not planned

Sitting quietly in a corner, deep into your thoughts/work and listening to your favourite tune.. “Hey! Can we quickly have a meeting about the XXX with the team?” What the.. why? I was..? why now?

Bet you were in that situation at least once, may be even more times and may have also finished the sentence starting with “What The..”. I can completely understand and this is mostly the reason many people find meetings interrupting. A meeting has to be done immediately for an “urgent” reason and the organiser (it can be you) have to define “urgent”. Just because you have some free time and want to get a thing or two done is not the right  reason to arrange an urgent meeting, whoever you are.

Plan the meetings and never assume that the people your are asking to join are free. You will not get things done in the meeting as the attendees are not in their right mind to discuss it. They are there because they had no other choice. May be you are their Boss and they don’t want to annoy you.

 

If your business needs frequent unplanned meetings, create time boxed meeting placeholder and send invites even if you don’t use it

I found this extremely useful in businesses where unplanned meetings are regularly necessary. Create a 10-15 minutes slot in every 3 hours and let everyone know. Everyone can use that session for any urgent discussion and not just you. Everyone will know that in their calendar, today they have 2-3 placeholders and they have to be free for that. If no meeting necessary, they can just continue working, simple.

 

Never attend a meeting with a mindset which reflects the attitude ‘it is a waste of time’

If you join a meeting thinking it is a waste, it will be. You will definitely waste your time and regret the decision of joining it. Worse, you may end up making it a waste for everyone else.

 

Never attend a meeting to control it, attend to contribute

The most important aspect of any meeting is, you can see everyone else’s view on the topic. You have an idea or a topic to discuss, you are pretty confident about the goal and have ideas to achieve it. So you invite others to ‘share their opinion’ on it. Stick to the goal, discuss and forget you organised it. Advocate your opinion but always keep in mind that ‘you may be wrong’. Just because you think it is right, doesn’t mean it is right for others. Contribute to the discussion with what you know and listen more to understand rather than waiting for the other person to stop talking.

 

Bottom line – If you can’t make use of the meetings don’t blame someone else. Meetings are necessary, useful and in fact improves the communications among teams/members in every way possible. Just make sure it is done right and not just a date in your calendar.