Manifesto for Agile Product Development – for any industry !

Original Agile Manifesto was neither confusing nor it needed an upgrade. It still remains the single most valuable source of common sense till date. The values & principles are still extremely valid and useful for software development industry and beyond.

However, over the years a majority of Agile enthusiasts realised that most of the values/principles can be reused on other industries as is, which has knowledge work involved. That’s when the term “Software” in Agile Manifesto became a constant topic of debate. Till date some still argues that it has always been about software and doesn’t apply anywhere else.

Here’s an attempt to clarify & settle that debate for good, as it’s not about anything other than effective product development that brings value to end users. The overall essence is very similar when compared to the original one.

Agility still remains a mindset, a philosophy and an attitude towards something better – on and on.

Hope you enjoy the read and spread the words.

 

 

For all 12 principles please follow the full article link here: https://preetam.de/agile-manifesto-2/

Justice League has a Single Point of Failure – Does your team have one too?

**Spoiler Alert** – If you haven’t seen the 2017 Justice League movie, reading after the below introduction may spoil it for you. It’s important to go deeper in the story to explain the intended purpose of this article.

Zack Snyder directed Justice League, released last year, is a great example on my team building workshops. Although, IMHO, this is not the best DC movie ever created in terms of mediocre script, predictable plot, over-hyped and overwhelming special effects. My complain is more towards the movie itself not the team. Only good part of this movie is, the absence of Superman – the humble man of steel. Usually, his presence is counter productive in strategic situations that need true leadership like Batman & Wonder Woman.

Not everything needs power, sometimes it’s about tuning down, so your team members can rise.

Most important fact we can learn from this movie – what happens when your most powerful member of the team aka Superman, gets “Hit by a Truck” or in this case already dead. By the way, this was apparently the 2nd most expensive movie ever made.

Single Point of Failure? – Guess What!

Detailed plot can be found here but I will only highlight the part that is relevant to our topic of discussion today.

Relevant Plot – The movie only shines for like 5mins when a zero memory Superman is resurrected. A small mistake by Cyborg’s reactive weapon angers the man of steel and the wrath of Superman begins when he alone dominates every member of the league and almost killed Batman with a pinch. Thankfully the contingency plan pre-calculated by Batman saved his own puny human arse.

Enjoy the moment below:

We all have seen a Superman in most teams; without a plan B when they turn hostile.

Let’s give you an example that might relate to our profession.

Think of a person in your software development team (or any team) – an exceptional developer with a plethora of domain knowledge is being “Productive” with his/her headphones on. He/she might also be known as a “life saver”. You ask a question and most probably get all your answers and your problem is sorted. The rest of the equally competent new team members have potential but lacks the domain knowledge collected over years. But it was never shared neither there are any documentation anywhere. The superhero believes he/she is too busy and someone else should do the useless documentation while he/she can “Do Some Real Work”.

Now imagine the below 2 scenarios when that person becomes the bottleneck –

1) When the Superman is “Hit by a Truck”

Now, one unfortunate day that awesome developer calls in sick before a product launch. After hearing that, if you don’t feel a chilling flow of blood running down your vein right now, possibly in the stomach, I have no words for you. It’s hard to even write about it as an example, as it’s so common. The next thing we know, the product launch is cancelled, stakeholders are furious and our lives are hell.

So what do we do? We call that same person, apologise for calling when he/she is actually unable to stand, requests him/her to connect to VPN and troubleshoot the issue. In most cases, it doesn’t get resolved and we are all in a over-salted pickle topped with habanero bits. Like what happened in the above movie. Superman is dead, so the world is doomed as we were relying on him too much the whole time and never thought of having a Justice league until the shit hits the fan.

2) When the Superman becomes hostile

The person isn’t sick but need a raise 😉 for obvious reasons. Performance review time –

Manager: As you know we didn’t make any profit last year, so no one is getting any raise this time. Not even me.

Superman: It’s not fair. I have been working hard, more than anyone else in the team and usually I am the only one on call even though I never get paid for those live issue troubleshootings. No one else seems to do that neither are capable to do it.

Manager: Well, yes that is true but you never wanted to document anything, pair with them or taught them how to do it either when they asked for it. I understand you are over stressed sometimes but it is because of the unshared knowledge.

Superman: When do you expect me to do it? It’s a 5mins thing when I do it, it’s 1hr when someone else do it. Are you saying you rather wait for an hour to get a live issue looked at or even fixed? Anyway, I will need that raise unless I will have no choice but to leave. I always help out when the company needs it, I deserve it.

Can you blame the superman in this case? Especially when he/she has a point.

Superman will never ask for help !

What we should ask ourselves:

Why wait for that moment to come? Why not be ready for a moment like this?

If you have been to this situation, the first thing you ask – “Only if we had someone who knew a little bit of this person’s work. Doesn’t have to be as efficient but to do the job in anyway, a quick fix” We have all been there and pulled our hair out.

The trick is to not tolerate a superman like the above. It may sound weird, why would anyone not want a superman in the team? Well a Superman is only necessary for short term benefits and when we keep repeating the behaviour and tolerate a dysfunction, no long term benefit can come out of it. Also it’s not really good for the Superman in the team which the person may never realise.

The reason a person tries to be/stay a Superman is to create a bottleneck so his/her presence is felt for personal gain, like the salary negotiations or promotions. There are some who don’t do it on purpose though, they simply are not team players and would rather do anything asked without even thinking if it has any business value at all. These members hinders creativeness among other team members who are equally capable but have their hands tied. On above scenario 1, no one wants to work and that’s their punishment if they are doing it on purpose.

In some cases, the person who is a bottleneck may be an introvert or very shy. it’s very common among developers due to the profession. Hence they may not even ask for help even if they know they need, making themselves overstretched in daily tasks. Eventually on one day this shy person won’t be able to cope and simple resign.

 

Create your Justice League before the Superman dies or turn hostile. Shared skills & knowledge are the key to crisis management.

Product Owners are torn between being the “Leader-first” and the “Servant-first”

When we talk about Servant Leadership the first role that comes into our mind is the Scrum Master. It is the first role ever, of it’s kind, which was created specifically for the sole purpose to “Serve”. Only if Robert K. Greenleaf was alive until 1998, he would be the happiest person to know that his whole life’s contribution has an effect on a dedicated leadership role; it changed everything especially the way we see management and leadership now-a-days. Then we started seeing the rise of “Agile Coaches” which was created, I guess, to differentiate that servant leadership exists outside Scrum as well in a equally dedicated role.

But this article is not about the Scrum Masters/Agile Coaches or their unbiased contribution to their teams. Today we are focusing on the role Product Owner (PO); the role which is often seen as biased towards “more and more work in less time”. There’s a reason.

According to the Scrum guide – “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team”.

This is often misunderstood by new POs and their organisation, where they believe it means “maximising the output from a development team”. It is not the same and that subtle difference decides if the person is a traditional Product Manager or a Scrum Product Owner. PO serves the development team (explained later) and ofcourse their job is to serve the organisation, but in very different ways.

For a Product Owner, Maximising Value ≠ Maximising Output

A typical Product Owner will prioritise and try to add work items in the Sprint backlog which may not be part of the Sprint Goal. There is nothing wrong with it, sometimes we have to, if we have higher capacity and we need a live bug fixed asap. As long as majority of the work relates to the Goal, we have a focused sprint.

Things start to become gloomy when a PO knows the true capacity of their development team but still try to negotiate to add that “small” Story, in case someone is free. That’s the biased “leader-first” side which overpowers the unbiased “servant-first” side, so that extra work can be shown as an achievement to a stakeholder who is constantly chasing. Typical phrase on these situations is like “If we manage to finish that too, we will make someone very happy when they are not even expecting it”. That’s a trap.

If it gets done, the stakeholder will assume it is not a one time favour and they can pressure anytime to get more work out of the development team, by going through the PO. If it doesn’t get done and the stakeholder finds out they will most probably be annoyed and blame the development team. Both have side effects and not a very good one. Both fails to manage expectations. On top of that, the development team will now feel guilty when it was clearly not their fault.

The trick is to align, orchestrate and trying to link the work items in a way which have a combined value to someone.

Value doesn’t always have to be for the end user. It can be for an internal stakeholder, operational requirements, legislation or something else. PO should fish for opportunities to “maximise the value” from any form of output. PO should known the capacity of the team from empirical evidence collected on past sprints.

Skill levels play a huge role in slowing down or speeding up the outputs, based on the team we are working with. If we have new team members, expecting same speed of development is futile. Know your team, know the people. If they are new and are on the learning phase, plan more Spikes and let them explore bugs raised which will help them learn the domain. It will also help the more experienced members on those domains, by collecting keys facts that can be used on next sprint. It helps everyone to keep the morale up and have a long term benefit.

Product Owner “Serve” the Development Team

As a Product Owner, we have to choose a “leader-first” bias as we are accountable for the product’s success but we can also serve when it matters the most.

  • While facilitating the refinement activity, PO focuses on the business value while keeping the known format of “must have”, “nice to have” and “can live without” in their head but never writes them down for negotiation purposes.
  • While fleshing out more and more acceptance criterion from all development team members, PO becomes their scribe and does the admin work which liberates the members who needs to think than focusing on where to add a comma or semicolon.
  • If a PO have to be part of the discussion, they ask for help from the Scrum Master to do the same. This is where negotiation begins but with a “servant-first” mindset which is backed by empirical evidence or UX decisions.
  • After Sprint starts following the planning session, PO serves the development team by being present on all the daily scrums to answer any query they may have. When they do this, they serve. Taking status updates is not a service; it’s an anti-pattern.
  • During the work day, PO again serves the team by simply being accessible to them by any mean. Just being there makes all the difference.
  • PO serves by not chasing the team members to create a sense of urgency.
  • PO serves by creating a big picture for each work and explain how it impacts the end users. Creating enthusiasm and showing the purpose is one of the most underrated skill.
  • PO serves them by showing trust on their commitment and being patient even in the most stressful times.

Product Owners are torn between being the “Leader-first” and the “Servant-first”

From above we can see where the true confusion lies and why POs may be torn between two contradictory ways of leadership. PO is accountable for the product success, a single emotional bias can affect the potential ROI. Unless they lead and focus on getting them done fast, it might seem impossible to even finish in time as every work has a cost of delay. We cannot have the “Servant-first” approach all the time with the development team as we are serving an even bigger team, the organisation.

When it’s possible POs can show the “servant-first” side but is it real? May be, may be not. Usually one person cannot be both.

POs will always remain biased towards the product, the goals and faster delivery. Reason why we have Scrum Masters to neutralise that dominance by guarding the development team when needed. Every role on Scrum has a purpose of why they are dedicated, this is one of many.

Are you a Product Owner, what’s your take?

Do you Lead first or Serve first?

Let us know.

What “TDD” stands for Vs What TDD is for

X: We need to follow TDD to reduce the number of bugs we get in live.

Y: Yes we might have to from now on. We also need to compliment it with BDD.

Z: Erm.. what does TDD have to do with live bugs? We need to follow ATDD.

Stakeholder: I simply wanted to convey the message that we are getting too many live bugs on feature “A”. May be that area need attention and few more tests to monitor the stability.

Common language and shared understanding is clearly missing on the above conversation. Partly because TDD stands for “Test Driven Development”. Self testing code is what we are after. There are many ways to write self testing code and TDD is one of the best approaches for doing just that. It doesn’t mean it is the only approach. Unit testing is the other more prominent contender.

Before we go further, lets expand the acronyms for those who are new to the concepts or new in the field of software development:

TDD – Test Driven Development

BDD – Behaviour Driven Development

ATDD – Acceptance Test Driven Development

TDD is NOT about testing

It’s true that we write a test before we write any code in TDD. It’s also true that we create a suite of tests that can be dependable during Continuous Integration (CI). What we fail to explain in this process, is to clarify a non-technical member that the core benefit of –

TDD is to help design an excellent architecture. The tests and the resulting suite are merely a byproduct.

TDD tests are robust and can confirm if a new commit have broken the existing build or not. Although, what it cannot confirm that if that awesome commit actually meets the acceptance criteria. A solid robust commit have every possible chance to be completely useless, unless we run end to end tests to verify the acceptance criteria. It assures quality but it is created by developers for themselves to clarify the low level architectural requirements.

A self testing code, hence, is a sanity check of the codebase’s stability and not necessarily a check on what the end users are expecting.

TDD is NOT the same as Unit Testing

Another way of creating self testing code is writing Unit tests after the code is implemented. The purpose is same as TDD, fast feedback about a commit. Although –

Unit Tests does not assure quality, it confirms an existing logic.

Why? Because the Unit tests can only see that a logic exists. Whether the logic is right or wrong, it is too late for that. Any test written after the code is implemented never assures quality. It simply confirms “yeah that’s what it does, no idea if that’s what it’s suppose to do or not“.

Assuring vs Controlling

Quality Assurance (QA) and Quality Control (QC aka Testing) have very different purpose.

  • QA prevents bug where as QC controls the known bugs to a manageable level.
  • QA is about discovering plausible scenarios as a team before coding, QC is about executing the tests manually/automated to discover edge cases after coding.
  • QA requires a whole team to focus on quality from the moment an acceptance criteria is written. QC is historically what all testers do and consider as their job.

Only if we focus on prevention early on, we may not need a dedicated role as a Tester. If you are writing the code, you should fully own the practice of confirming if it does what it’s suppose to do. Anyway..

So, TDD assures the quality of the design & architecture, which is great but not enough. Integrations tests and the end to end UI tests on the other hand are about QC. It certainly depends on when they are written – in ATDD they are written before the code is implemented. Not many companies follow ATDD, reason why most Integration & UI tests are written too late after the feature is already deployed on a staging environment.

In fact, we write these tests NOT to “test” anything; we write them to save time during regression testing, to save manual effort of repetitive tasks and cover our arse in the hope that the end users/stakeholders might accept the iteration, that’s all. It’s a team responsibility to assure quality not any particular individual’s.

TDD is not mandatory, neither is evolution

If we don’t consider scaling as a viable option in any near future, then feel free to ignore TDD. Truth be told, any software we see today always need scaling and an evolving architecture. To evolve we need constant refactoring and continued attention to the design and architecture.

Non-technical members won’t get this, neither you have to ask them. You, as a developer, thinks it is important – good enough, just do it while being transparent about it. Need to add few extra velocity points? Go on then, it’s necessary – it isn’t a theory. Technical debt is a reality, might as well pay the debt while you can.

As a developer, if you can’t see the benefits yourself, good luck explaining the benefit to someone else who only cares about faster delivery of error prone “working software”. It’s your job as developers to raise awareness and build quality in to prevent waste of time later.

End Note

Whether we think TDD benefits us or not, it’s always a very good way to constantly be agile and stay agile. Evolving <anything> is what we need and TDD closes that gap by reducing risk on low level and ensures a great quality architecture. Don’t focus on what it’s called, focus on what it’s suppose to achieve. ATDD and BDD both compliments TDD, not replace it. They simply have very different purposes even though many “think” these are all about testing. It’s not, it never was.

Stretched Target on a Sprint? Please Stop!

In the last few days several people have asked me a question about stretched targets on Scrum sprints – not sure if it was a co-incidence or an ongoing vibe. So I will take a moment to explain it.

This article will not revisit the negative consequences in detail of having a stretch target. I will assume the obvious with a quick recap, so I can focus on the solution in detail rather than discussing the problem.

Quick Recap – Why do we think we need it?

  1. When we feel the need to manage a person rather than the work they do.
  2. When we focus on Efficiency over Effectiveness.
  3. When we focus more on tools and practices more than the principles behind them.
  4. To impress stakeholders they need everything “right now”
  5. To impress authority by over-estimating our capabilities
  6. When we assume – “What happened last sprint won’t happen again”
  7. When we don’t trust a team member and say “We need to keep them busy”

How can we avoid Stretch Targets?

A) By focusing on the flow of work that matches the business need

This part covers the solution to 1, 2 and 7 mentioned above. It’s a topic which majority may not find an issue with. It’s so subtle yet so powerful that we assume “That can’t be a solution ! It’s too simple to be a solution”. Yes, it is simple and that’s why our urge to over complicate simple things gets on our own ways.

A good example of flow of work

In a development team, either Scrum or Kanban, we have a known trend of monitoring work. We plan the work – then implement it – then we test it – then we release it. Testing is always a part of implementation but majority still assumes it’s a separate practice that has to happen and hence you will see a swimlane similar to “In Testing”. Separate topic perhaps.

On this above setup, we see a board with columns as many as 10 or more on some cases. Like – To Do, Re-opened, In Progress, In Code Review, Ready to Merge, Ready to Test, In Testing, In UAT, Ready for Production & In Production.

This – is what we will always see when we are focusing too much on who is doing it and getting paid instead of what are the value of tracking them. As a business, do we even give a shit if it is being code reviewed? That’s a habit, a practice, a step which ensures quality of code.. and in an insignificant information for anyone outside the development teams.

“But we as developers need to track it for ourselves” – yes, true. But it is a second nature that you should be doing anyway. You wake up every morning and brush your teeth, it’s a habit. You don’t have to talk about it nor should I care. Well, unless I am your dentist 😉

Truth is, developers do it to show the state of the progress as they fear some might think they are slacking. When this becomes a norm in any development team, stretch target becomes a norm too.

It’s normal to see on the last few sprint days, there is nothing in ‘To Do’ or ‘In Progress’ – so we assume that the developers are doing fuckall and getting paid for free.

Therefore, to “keep them busy” we add a stretch target in the planning session to utilise the “Resource” efficiently if needed. Result: Always a sprint where we never manage to finish the committed work and our moral goes down. We know it will bring zero value in our sprint, as anything we start that late can’t be finished by the end of the sprint.

| Planned | In Progress | Ready For Release| Released |

Solution is simple as above, create a board to support the tracking of effectiveness towards the business. Use the remaining timebox to work on Spikes/Investigative work that may help refining the backlog rather than starting a new work.

B) By accepting the fact – “History repeats itself” – more often than we think

How many times have we said “It happened that one time and it will not happen again”. Then saw it happening again in few weeks or even days. Truth is, what is happening within a specific scenario is not related to that specific scenario. It’s the surrounding of it.

The environment that caused your sprint to fail is not the sprint itself, it’s the same rehashed “cultural” factor that was the culprit. So until the core issue is resolved, that by the way, everyone knows but can’t remove.. we should have a buffer.

e.g: You have 5 live bugs due to a serious tech debt issue. It took nearly half the sprint capacity out resulting in a chaos. Expecting that we won’t get another 5 bugs next sprint is simply fallacy.

Even though we know we may not get a whole week due to live bugs, we still manage to add a 2 weeks of work in the “Hope” that there will not be any bugs interrupting us. That planning you just did for the 2 weeks of work is there is already a “Stretched Target” based on false hope and false promises to stakeholders. Assume that the worst can happen again next week and rather than pushing more work, wait to see if we get free time when a developer can “Pull” the work instead.

C) By impressing the one, that matters the most

Impressing a Stakeholder is not the goal, certainly not when they have no data to prove that the theory they have about this new features becoming popular is correct. Impressing a Product Owner is not the goal for the same reason. Goal is to impress the one who is paying aka your end users. PO and therefore stakeholders are being the “messengers” for the development team and should always have data to prove the hypothesis before implementation.

If as a development team member you fail to ask for data, then don’t start crying about it later either. Refinement and Planning events are your chance to ask these questions and understand the context. If you don’t, you will allow these stretched targets to be placed in your sprint backlog and therefore will be responsible for your own unhappy work environment.

If you as a PO is pushing work as a stretched target to impress a stakeholder without knowing the actual capacity of the team, again, you are making a false promise. This is in your best interest to not commit extra work that you know are stretch targets. Certainly don’t promise based on assumptions like these. At the end of the sprint you will find an unhappy stakeholder and end users, even though your team was focusing on critical bug fixes to help them. You won’t get praised for those values as bugs fixes never get complimented rather criticised heavily with less informed phrases like “Bugs shouldn’t exist” or “Fix the bugs on your own time, I need my new feature”.

D) By being transparent about the true capacity

You know it’s summer time. You know half of the people have families. You know majority of them have kids who will not go to school due to their holidays. Also, you know some of them have booked a whole week off in advance, as early as 2 months.

If these above facts are being ignored in sprint planning, even a small story can become a stretch target. True capacity is when you ask the team about their “Gut Feeling”. I call it the “Gut Feeling Driven Development (GFDD)” where you think as a human, with your natural instincts and intuitions.

e.g: If I have booked my holiday from next Monday, I would probably fly out on a Friday night so I can use the weekend days to settle down and start enjoying the real holiday from Monday.

Yes, majority of us do it. If you don’t then you read the protip here first 🙂

So, if we are leaving on Friday night without leaving earlier than 6pm officially, we have to be well managed. I know few people who print their tickets off before leaving, calls the cab and web checkin so they have enough time when they arrive at the airport. Human do this, we all do this. That’s natural and no one will tell you to stop doing it. Therefore, our gut feeling will say that we will probably not be productive enough after lunch on the Friday to work on a complex refactor. Hence we should probably not commit that extra bit which have some unknowns.

It’s good to have a plan but it is more important to know that the plan can go out the window due to a stretched target. If this happens continuously we will feel demoralised and frustrated time to time.

Stop setting “Stretched Targets” in the hope that it might get done; it most probably won’t.

NOT Scrum when we..

  1. Write it as SCRUM – It’s not an acronym.
  2. Create user stories – It’s a XP thing and a very good way of documenting expected outcomes not requirements; there are other ways too.
  3. Do a “Stand Up” – Daily Scrum is important, standing up isn’t. Next time feel free to relax. Just finish it within the 15mins timebox.
  4. Measure Velocity – Especially with a modified Fibonacci sequence like in Planning poker. Estimation is important, estimate isn’t.
  5. Create a Burndown chart – It used to be a Scrum artifact and has been removed because it doesn’t provide any new information that we doesn’t already know.
  6. Focus on Iteration – Increment is a Scrum artifact not Iteration. If there is no improvement based on empirical evidence in the process or product, it’s not Scrum. This is why there’s a steady cadence of a feedback cycle aka Sprint Review.
  7. Implement any practices like TDD, Pair programming or continuous integration – These are, again, part of XP not Scrum. Whether you do it or not, it doesn’t matter as long as you are providing a working software with valuable outcomes in a good quality when the sprint ends.
  8. Miss a Retrospective – That’s when we inspect and plan to adapt. In fact it is the most important event of all. You cannot cut down a tree with a blunt saw.
  9. Hire a mixed role as a Product Owner/Scrum Master or Scrum Master/Developer or weirder combinations. You might think you are saving money, you are not. You are risking to loose more than double of the amount you think is being saved.
  10. Not read the Scrum guide or share it with everyone involved. Any description or roles and responsibilities not referring to Scrum guide is an attempt to implement zombie scrum.
  11. Not set a Sprint goal or not taking seriously when set.
  12. Have a line manager who is against the notion of agility and Scrum by default.
  13. Swap work items after sprint starts, resulting in a change of scope. Again it’s a XP thing, not Scrum. Doesn’t make it bad, but we should know why we are doing it.
  14. Change a sprint length regularly to meet deadlines.
  15. Not include QC (aka test execution by Testers) within sprint to get more coding done. In fact, this is frankly the worst practice of all. Also, by the way, there is no “them and us”.. you are all “Developers” if you are being part of development hands on.
  16. Blame Scrum for our own failure to improve, which Scrum has exposed.
  17. Think of Scrum Master or Product Owner – as a Project Manager.
  18. Think Scrum helps in delivering faster. It’s not about fast delivery, it’s about knowing if we are doing the right thing. Doing the things right (good practices) is actually not even mentioned on Scrum at all.
  19. Agree to work on items which are not part of the sprint. You are only screwing with yourself.
  20. Allow PO to make changes on sprint backlog
  21. Allow Development team members to make priority changes on Product backlog.
  22. Allow Scrum Master to touch any backlog or make changes in the absence/permission of the respective owner.
  23. Allow Scrum Master to get daily update on “what have you been doing? I saw you chatting more than working”
  24. Allow Product Owners to add “stretched targets”, in case you run out of work.
  25. Say “We are developers. We like to code and we hate when we are invited to a refinement meeting. It’s not our job.” – Yes it is, if you are in a Scrum team.
  26. Assuming a Scrum Master is your “Master” – Read Scrum Guide v2016.
  27. Commit to more work on planning and fail to deliver, creating distrust with a permanent damage on expectations – Commit less, make sure you are capable of finishing it. If you have free time, let PO know so he/she can add more work for you – Pull it in, you are controlling the work intake while making stakeholders happy.

 

Have you came across more anti-patterns of Scrum like these? Feel free to add a comment and it will be added in this list crediting you.