Category Archives: Product Development

The Manifesto for Playful Product Development

Posted on by

Guest Article written by Graham Holden – here’s a little something about him in his own words:

Graham describes himself as a Programmer, Scrum Jester, Shantyman.

Has been working within the internet industry since 1997, for a variety of organisations.  Has a passion for programming and helping teams become effective.

******************************************************************

 

In Peter Greys Book – Free to Learn (thanks Tobias Mayer (https://tobiasmayer.uk/) for recommending this), he emphasises the importance of Play for children’s learning and development. As a parent, I’m often conscious of not interfering in the play my children embark on. I’ll be present, so that if they need me for anything I can help – but I like to let them get on with things.

Peter Grey outlines Play as the following :

  1. Play is self-chosen and self-directed; players are always free to quit.
  2. Play is activity in which means are more valued than ends.
  3. Play is guided by mental rules.
  4. Play is non-literal, imaginative, marked off in some way from reality.
  5. Play involves an active, alert, but non-stressed frame of mind. (https://www.psychologytoday.com/gb/blog/freedom-learn/200811/the-value-play-i-the-definition-play-gives-insights)

 

It got me thinking about how, when I am programming for “fun” it’s actually me “playing”.

I feel that the 5 “rules” above could be adopted within organisations as a framework. Some might say business is a serious thing, and there is no room for frivolity. But what a lot of us have forgotten, is that as children when we “played” it was serious. When you are in the midst of it, play is all consuming – it is an example of a perfect state of “flow”.

I would encourage organisations to adopt the framework to help teams use play for personal development and learning. This would be a great first step. In the past I’ve been involved in some interesting breaks organisations have put on, these have been called “hackathons”, “hackdays” or just “learning days”. The most successful ones have essentially followed the basics of the framework outlined above.

  1. The Teams chose what to work on, and could switch to other teams if needed.
  2. The experience of the day and the activities trumped the actual end results.
  3. The teams got to work how they wanted, with what they wanted, and produce whatever they wanted.
  4. The teams could work on whatever they liked.
  5. The teams had very little pressure on them, there were no KPIs.

 

I believe more and more organisations should be adopted playfulness at their core, and we can have a playful movement for product development.

 

“When” to focus on documentation in Agile Software Development?

Posted on by

The only time “Documentation” was ever mentioned in Agile (aka in the Agile Manifesto) is in this statement –

Working Software over Comprehensive Documentation

Followed by a very important warning which many manage to neglect – “That is, while there is value in the item(s) on the right, we value the items on the left more.” From that, unfortunately, a ludicrous idea of not documenting at all has been generated over time.

LackOfDocs

Still a Radical concept!

Being part of many debates over years on this topic, it’s obvious how this area of the manifesto is less explored. Which is why Business Analysts and Product Owners are still wondering when to document in the Agile way or should they do it alone. Collaboration is key.

Sure – BDD helps us document user stories with collaboration and help create the Acceptance Criterion for planning discussions. Some have successfully established ATDD which helps in writing failing Acceptance tests and creates an exceptional red-green-refactor cycle similar to TDD.

BUT

Among all these, a developer still wonders WHEN do they document the intricate details of the technical architecture, necessary information about a dependency and system designs while supporting “Technical excellence” without which no one can really become agile. We can tell each other that TDD helps us in focusing continuous attention to architectural detail, but how many developers actually use it and writes a test before each line of code.

There are many cases where the product documentations are nowhere to be found as the developers were told during planning – “We are now doing it the Agile way and all you will get are a bunch of statements written in Gherkin syntax.”

Agile Principles clarifying the WHEN

#2 Welcome changing requirements, even late in development.

We are seeing changing specifications in a weekly/monthly basis. Based on the type of business it’s highly likely to see changing expectations on a daily basis as well.

Can we really document anything before knowing what to build? Give it a deep thought.

When we talk about User Stories – most popular technique for specification gathering – we are not documenting a requirement. We are starting of with WHY, the least amount of known high level outcome, with or without knowing how the output might look like.

If a team never documents anything else other than the stories, that’s when it starts getting impractical with a huge risk to quality, understanding and sustainability. Documentation is required.

#7 Working software is the primary measure of progress.

Traditionally we have learned to document first as we used to plan heavily to begin with. We know how that’s against agility according to Cone of Uncertainty. We can never know about a feature/specification well enough when we start of. We learn through early feedback on iterations that can generate enough discussion.

Reason why we should build a piece of software first based on high level WHYs and review how it may look like. Once confident and final on a characteristic or functionality, then we should document.

Only document to record evidence of a built feature which is accepted.

#9 Continuous attention to technical excellence and good design enhances agility.

With even changing specifications on continuous feedback, we need even changing updates on the documentation in real time. Documentations essentially should reflect current state of affairs rather than what we hope it could be.

When working in huge organisations where a single monolithic code base is being used and updated daily/weekly by many many developers, that’s how chaos starts. Documentation should be in codes – true. It is also true that not every developer are capable of doing it as we hope they do. If they can’t in the code, make sure they do anywhere else that can be shared and available for everyone.

Duplicate documentation is better than no documentation, as long as they provide the same recorded evidence.

Conclusion

Therefore, the original manifesto statements about “.. over comprehensive documentation” actually translates into the following:

First build a working piece of software and then focus on documenting how it was built and what it does, for shared understanding.

The only way to “Empower”​ someone

Posted on by

Time and again we hear professionals talk about empowering a being and how it’s the right way to go. How empowering a gender, race, team member or an organisation helps in improving accountability, ownership and peaceful collaboration. How this makes a robust community of respective subject matter to cohabit with shared goals.

Love the idea, it’s marvelous to see many people are embracing these great ideas. With that in mind, I asked handful of them –

How do you empower someone or a group?

 

Majority of the replies had a short pause, usually with a raised eyebrow, followed by a somewhat vague response like “By giving them chance to see the big picture, allowing them to contribute to the greater cause, authorising increased accountability/ownership and removing anything that blocks them”.

Seriously? Isn’t that what we should be doing anyway?

Technically anyone who is claiming to “Empower” someone is not really doing anything productive. Rather they are stopping their own unproductive interference. They are simply backing down from where they shouldn’t have been in the first place and they are taking credit while they do so. *Mind Blown*

Truth you came here to find:

The ONLY way to empower someone, is to stop dis-empowering them.

And stop taking credit while doing so. If we do, we are again not really giving them the credit they deserve while we steal the attention.

A person/group can be “Empowered”, only if they want to be!

The notion of empowering a being or a group also creates an illusion that it’s in our control. Sadly it isn’t. Fact it, if a person/group doesn’t want to be, we cannot really make them. It’s a personality trait where some like to do what they have been told.

What sort of person wouldn’t want to be empowered you ask?

  • “I did what I was asked, ask X who owns it now”. Silos – yes, some do love it and it’s all personal.
  • “Trust me I want to help but last time when I tried, your manager turned on me and requested me to mind my own business” – Fear of rejection.
  • “I told you this wouldn’t work. I can help you if you like? No? Alright then” – Ignorance of Skilled opinion over superiority.
  • “No, don’t want to get involved again. Last time I made a mistake and it affected my bonus. It was not even my domain of work.” – Outdated and demoralising KPIs

What can we do about it? Surely we can do something to Empower as Leaders

There are many ways obviously. I have found the following are good enough to start with –

  • Give them an achievable goal and back off. Support and Serve. Delegate and show trust. Allow failure that can be reversed. Make sure they understand they failed and ask them what they learned from it. REPEAT.
  • Find out what the impediments are and why can’t they remove it themselves. Let them try. If they ask for help, without passing a judgement first sort it out. Revisit on how much more we can/should do to remove the blockers in future. REPEAT.
  • Tailor our KPIs based on Team goals over individual performances. If we really care, let peer pressure handle it and monitor how are they performing as a team.

 

And yes, we should stop empowering people or tell ourselves that we can somehow.

As leaders, create a sustainable culture where people can Empower themselves.

“Agile”​ in Scrum​ context – It’s not what you think it is!

Featured | Posted by

Almost everyone within a software industry must have heard about “Agile” or “Scrum” or both on every project management context. People often use them interchangeably to refer to something that matches with their confirmation bias. It’s appalling how both are misinterpreted, tailored to avoid change and lied about. It causes irreversible damage to a company’s growth, revenue and prosperity guided by employees who may have no idea what “Agile” and “Scrum” actually stands for.

Few common misinterpretations of “Agile Scrum”

  1. Scrum will make you Agile
  2. If you want to do Agile, start with Scrum
  3. Scrum is a great training wheel to become Agile
  4. Scrum is a branch of Agile Project Management

Each of these misinterpretations will be explained later in this article. Feel free to scroll down to that section, after all it’s part of your daily social media read. Although I would strongly suggest you read the following material before that.

Scrum isn’t about “Agile”

If you believe in Shu Ha Ri way of learning, please do the following as your “Shu” step –

  1. Open the following PDF online (No it’s not a phishing link, it’s the Scrum Guide)
  2. Search the word “Agile/agile/AGILE” within it.
  3. Note down the number of times it appear in the PDF.
0

The number of time it appears here = The amount of truth you have been exposed to when you first heard about “Agile” in your career.

Now, search for “Goal” in the same document. If there’s no new version of this live document since I started writing this article, “Goal” should appear 37 times.

0 (1)

Scrum is about setting a Goal which is the base of every discussion, development and mechanics to achieve it in a time box, Sprint. Then we inspect and adapt the goal.

If that makes us “Agile” – it’s simply a useful byproduct. It’s not the intent and reason why a lot of teams fail in establishing basic agile mindset/attitude within a Scrum implementation. They are simply chasing the wrong intent. Failing that they end up blaming Scrum and Agile. It’s doing more harm than good.

Agile (noun) vs Agility (noun) vs Agile (adjective)

This may sound like “Old shit rehashed”. In fact it is, but with a twist. It has been mentioned, told and explained many time by many professionals in several occasions. Feel free to scroll down to the next section if you heard this before.

Agile (noun) – Usually refers to the Manifesto for Agile Software Development. These are a selection of carefully worded statements which radiate Simplicity during collaboration.

Agility (noun) – Refers to the true essence of the above, it’s values and principles. This is misinterpreted often, as we cannot measure this by numbers or metrics. Can you measure your principles and values?

Agile (adjective) – This is misinterpreted in way many cases and by far the most useful way we should approach a solution. To be agile doesn’t mean “fast”. It’s about being “adaptable” on our approach to achieve a focused goal with no set rules, practices or methods. Turn when you need to, where you need to and how you need to – but focus on the valuable outcome.

Can Scrum be the way to Agility?

Sure. Scrum can be one of the ways but being a framework, it doesn’t include any method, practice or techniques. This is on purpose – because, again, it’s not about making us Agile.

Scrum is about complex product development where, at most part, the output is unknown but have a possible outcome as a goal.

“Complex” can be subjective. Easiest way to know when to use Scrum is asking this question to yourself – “Do we know what we are building?“.

If No, you definitely need Scrum. Forget about being agile, you have no idea what you really want to build. You have a clear “Why” in mind and you need to get there by any mean possible.

If Yes, there are 2 ways to interpret –

First – may be you think you know but you don’t. How sure are you?

Second – may be you are right. Then you probably don’t need Scrum.

Clarifying the Misinterpretations

1) Scrum will make you Agile

You can follow Scrum by book, exactly as it says on the Scrum Guide. You can have dedicated roles as it suggests. It is still possible to be not be agile. Here’s how the Scrum roles can be misused –

Product Owner (PO) – Starts dictating the product roadmap without consulting anyone. Becoming a Stakeholder (not customer) proxy with no real input based on data or own analysis.

Scrum Master (SM) – Starts managing people rather than the flow of work, thinks of him/her as the team’s manager and collect stats on how many hours the DTMs are working.

Development Team Member (DTM) – Starts dictating the technical aspects way before the intended value is established, disregarding PO or SM’s suggestions and creating an anarchy which leads to well engineered product which no one will ever use.

2) If you want to do Agile, start with Scrum

If doing “Agile” is the goal, the person needs to read the Manifesto few more times before saying those words. You cannot do “Beautiful” or “Nervous” or “Green” or “Strong” or “Happy” or “Surprised” or “Spicy” – wait where was I? Of yes, stop doing things which are descriptions. And if you are doing the nouns, I would be very concerned on a very different level.

“You know” – No, I don’t know. Unless we start using the correct semantics, we should stop discussing anything around Agile or Scrum.

3) Scrum is a great training wheel to become Agile

This is by far the most sophisticated way to sell Scrum. Selling is not bad, although selling a solution that doesn’t help remove the core problem is wrong.

I am a servant leader and I am freaking proud to be one. Although, I would never recommend anyone to implement Scrum just because they want to become Agile. Everyone should suggest a solution which is appropriate to the problem. You call yourself a Scrum Master or Agile Coach or Enterprise Superstar.. just don’t sell a hammer when they need a scissor.

Most companies we work for do know what they want as they have a huge requirements pool (1000 Tickets on a Jira backlog) already setup. They intend to break them down in chunks as “Sprints” and call it a feedback cycle. If they have everything prepared, may be a well governed Waterfall is a better choice isn’t it? Why bother with the names like Scrum or Agile or similar?

If you want to become Agile, focus on value and the value stream.

4) Scrum is a branch of Agile Project Management

No comments, except, on behalf of all true Agile practitioners –

Lead time & Flow efficiency measures a system’s Efficiency – Not Effectiveness

Featured | Posted by

X: We have to improve our Flow efficiency & Lead time.

Me: How come? Our Flow efficiency is around 50% which is actually better than most development teams.

X: Yes it’s above average but still not reflecting on the revenue though. We need to improve it even more, some even have 80% which I think we need.

Me: I have my doubts. We have made the system as lean as we could. If we push too hard, we will start hitting bottlenecks. Also we are not a manufacturing company so we have no choice but to keep experimenting new features.

Neither of us above were totally wrong. We simply had different opinions towards what was important for the business under discussion. “Business” – what kind and why it exists is very important here. Not all businesses can achieve high flow efficiency as they have to experiment too much and fail many times to understand the end user’s real problem. Value is what we want to focus on. To make sense of this article let me define what efficient and effective means to me:

Efficient – Moving from A to B within a predictable system and defined route, repeatedly. (Manufacturing)

Effective – Starting from A with no idea where B is and identifying several options to get to B or C or D. (Development)

My views comes directly from few known facts –

“Nothing is less productive than to make more efficient what should not be done at all” – Peter Drucker

“Simplicity–the art of maximizing the amount of work not done–is essential” – Agile Manifesto, Principle #10

An Efficient system (simplified)

This (below image) is what we can think of when we talk about an efficient lean system with reduced waste. Vast majority of the system is being used to work with a good Flow efficiency of around 80%.

There are few prerequisites that we often ignore. The most important one is “Predictable” work flow. We can plan to remove every muda (waste) we find and can end up in an extremely lean and efficient work flow that produces a desired output with perfection. Problem with that is, we assume the same Lean principle applies to every knowledge work which cannot be predicted at all. All we can really do is to project a trend based on historical data and come up with an average, which again may or may not be useful.

If the Business is about making predictable product with TQM and adherence towards a specific output repeatedly, higher Flow efficiency is a must. This is hence necessary for every manufacturing business where development (R&D) phases usually exist out of the structured and well defined lean system to meet the high demand of a predictable product.

A sudo-Effective system (simplified)

sudo-Effective: An efficiency focused system confused as an effective one while trying to use Flow efficiency & Lead time as their KPI.

This (below image) is what we can think of when we talk about a sudo-effective & partially adaptive system. Vast majority of the system is NOT being used to work with a rather poor Flow efficiency of around 20%.

In the above example, the Discovery & Prioritisation is shown as a separate phase which is true for many companies. A request from a customer or stakeholder stays on a product backlog for quite a long time without getting prioritised for months. When it eventually gets prioritised, it might be too late and may have lost it’s intended value completely. I am pretty sure a majority will relate to this example as this is the naked truth of majority of so-called “Agile” departments of an organisation.

An Effective system (simplified)

This (below image) is what we can think of when we talk about a truly effective & highly adaptive (agile) system. Vast majority of the system is being used to work but in extremely unpredictable fashion with overlapping development phases. The majority of the system is focused on doing the “right thing” and frantically experimenting all possible outcomes and collecting feedback on the go.

Are we building the right product?

This question is being asked, as the business regularly faces the challenge of changing requirements heavily influenced by continuously improving competition and their new products. It’s neither predictable nor has an option to make it lean by removing waste. In fact, it is full of wastes that the system is actively creating to learn what doesn’t work.

The Flow efficiency can be very hard to establish in such systems making the KPI irrelevant in this case.. working prototypes are the true measure of agility. We shouldn’t measure Flow efficiency when true effectiveness has to be achieved.

Agility is about continuous adaptation, Lean is about perfecting an adaptation. Providing value is a common goal for both, in very different context.

Some recently posted wisdom from influential & respected community members around it:

Value – Define what it means for the Business in context!

Be it Lean or Agile principles, both defines Value as end user consumable products/services. Who the end user is, defines what the Value might be and therefore what principles to follow to provide that value.

Few example of industries and recommended focus

 

Product Development aka R&D – Based on current generation’s need we have seen time and again that being adaptive is what make or break it. If a development team focuses too much on lean principles to become super efficient, there is a good chance that they forget to consider whether they are really working on the highest priority value according to the customer’s need. They start focusing on processes, tools and intricate mechanics with a partial or complete disregard of the “WHY”.

Hence the recommended focus of such teams and organisation should be to follow Agile principles to become more effective while keeping the necessary efficiency which supports it.

Service Delivery – Any company responsible to provide a part of the system usually 3rd party service providers. consultancies, call centers etc. you name it. Every such industry have very different end users with very specific definition of Value.

For simplicity of explaining, say you are part of an IT consultancy who is responsible to migrate all data from a decade old infrastructure to AWS. There’s a good possibility that the steps necessary for the most part is a mix of finding unknowns and known facts about the migration. End user is the company paying for the service to get it done, a consultancy has quoted a price & date to make it happen. For the consultancy the value hence is defined as “Provide solution by <date> with a £x budget all inclusive.”

To Conclude

There is no right or wrong, just a variable business context and how we define “Value” as.

Sometimes we want to focus on efficiency and sometimes we focus on high effectiveness over efficiency. If you are measuring Lead time or Flow efficiency for a development team, be prepared to get a useless KPI which neither helps you nor the team developing. Measure what is needed to achieve the value rather than trying to fit the same principles everywhere. A simple rule to remember where to apply –

1) When we hear “development” assume obvious complexity, unknowns, learning and adaptation where Lead and Cycle time is very hard to establish.. and at best can be totally wrong. Be agile.

2) When we hear “production/manufacturing” assume predictable known steps with defined output at mass where Lead & Cycle time are extremely useful KPIs. Be lean.

Manifesto for Agile Product Development – for any industry !

Posted on by

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/