Gallery

Debate Settled – 9 women can deliver a baby in 1 month

“More people” equates to “less time” for the same amount of job, right? When we search for “9 women can deliver a baby in 1 month” in google, it usually brings back results which suggests every “Project Manager” thinks like that in the world of software development. Here’s the proof:

 

I disagree on the fact that “every” PM is like that. Anyway, this article is not about a PM though. It’s about anyone who thinks and act the same way as it highlights in the joke. This joke has another dark side which suggests it’s easier for “any person” to think the same.

Let me be the devil’s advocate for a moment and prove that it is in fact possible but isPointless !

Biology as an Analogy

A baby stays in the mother’s womb on an average 9 months, before being officially “born” (natural birth as an example). Dad’s sperm invades mum’s ovule after competing with a million of inferior competitors. Survival of the fittest. It forms an embryo and begins a new life in a state which technically should be known as the moment of birth.

Imagine a Sci-Fi Movie “1 Month Baby”

Goal – Deliver the baby in 1 month

Hmm.. we have only 1 month to make this work and modify the human anatomy so it can produce each limb/body part of a baby separately on 9 wombs.

9 parts are (for simplicity) – Head (1), Hands(2), Legs (2), Chest compartment plus Respiratory organs (1), Spine and back (1), Buttocks (1) and reproductive organ (1) which decides if it’s a boy or a girl. 9 woman volunteers are chosen to make this happen.

To support this, each woman is specialised to deliver a particular organ/part effectively in the given deadline. The incubation period starts off well, everything is hunky dory. It’s a movie so there has to be a twist isn’t it? One unfortunate day, one of them got hit by a truck. Laying in the hospital bed she is not thinking about her own broken spine, she is thinking about the damage to the “head” inside her. Although it’s not a whole baby, it still is a baby for the mother.

Now the plan was to synchronise and deliver all parts on a single date, so we can eventually get a fully grown baby. The accident damaged the head and is not fit for purpose anymore. So the baby will never have a head, which is in fact the most important bit. So basically after a month there are 2 options –

  1. Let the baby live without a head
  2. Declare failure and blame the mother for getting hit by a truck

On top of that, questions will be raised on “Ethical” subjects –

  1. Who gets the baby after all this? Who will be called as the mother?
  2. To do this, don’t we need 9 specialised “Men” as well. So who will be the father?

FFS.. this is getting out of hands, lets plan a sequel to cover that subject later !

Back to Reality !

Question: Have the medical science managed to find a solution like that yet, in real world?

Answer: Not yet, phew ! But we are humans. We are good at breaking nature’s law for our selfish lives. We may one day able to do it in the name of “best breed” of babies. After all, human are playing the new god.

I believe, we should just iterate over each stages of development, on the same baby. It’s only natural.

 

Do you have a better option under your sleeves? Let’s explore it then, shall we?

Leave a comment !

Gallery

WWWA – #3 Experience of Customer Service is Mandatory to get Agile

WWWA = What’s Wrong With Agile

Hope you had (is having) a great long Easter Holiday with your family. Back to reality.

A quick recap to the goal of this series, which will stay same on every following article – to make some space in our brains for this to stay in:

 

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

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

#3 – Experience in a Customer Service role is mandatory to understand Agile

Agile is still very much a software development philosophy that we are trying to adopt, mostly due to the fact that it was born within it. Although it applies to any product development as we already know. The candidates who wants to know more about Agile are somehow connected to a career around software development. That’s the biggest blocker in establishing a company wide Agile mindset as it is not considered suitable for everything else. But to understand Agile, we need that consumer focused environment on areas other than software.

 

People – We tend to avoid the term “Resource”. It’s disrespectful to call someone that. Semantics may seem irrelevant at times but are way more important than you think in this context. If you are letting someone call you a resource, you are equally responsible to what comes after. This “People” aspect is what makes it necessary to understand your consumers and get experience on how to serve them. Yes, you “serve” them by not following all instructions they tell you to do. You stay focused on delivering a good customer service.

Serve as a Doctor and not as a Servant.

Before we go deeper in the subject, we need to explore a key aspect of our surrounding culture, the people.

Personas surrounding Software Development and Agile et al

The Hard Workers

Future aspirations includes but not limited to moving on to a managerial/leadership role.

A typical software development professional get where they are by taking the formal route: the learning phase such as BSc, MSc, PhD or similar. Building a software is a knowledge work right? It require investment of multiple years of hard work trying to sharpen those specific skills that helps in doing the technical bit of software development. After all that technical bit is the “actual work” isn’t it?

For MBA (or similar) graduates it’s the non-technical bit that matters the most and ofcourse it’s much better than the the low level work carried out by the technical “Resources” isn’t it?

They all start off with a theory they have (or given) and aim to apply it in practice as a career on their respective fields. “Freshers” are therefore more comfortable in a controlled environment as that’s what their environment was during the learning phase. That’s what they have been taught and that’s what they have been asked to write on exams. Unless they won’t get a ‘Distinction’ required to be placed in an organisation providing “Internship”. They are usually behind (module wise) when compared to the real world.

The Vampires

Future aspirations includes moving up on the ladder to a role requiring Technical Excellence

These are the over enthusiastic kind – the non-academics who excel in every aspect without a formal education. These borderline vampires were busy being that nerd who hates direct sunlight or something. No, it wasn’t me. These form a majority of extremely good developers we see around us today, simply because it’s their passion. Most probably then don’t even consider work life as a separate part from their personal life, which is not necessarily a bad thing (up for a debate).

Road to Customer Service

During these learning phases very few “lucky” academics and non-academics above work (or got a chance to work) in a consumer facing environment e.g. sales, retail, call center or a restaurant. You will find out soon why they are lucky. How do we expect the majority of these candidates to learn what “feedback” means? How do we propose they learn about making a “end user happy” while staying in the boundaries and policies of their controlled environment? How can they possibly know what it takes to be “fair” and honest when they themselves are confused? The dissertation which some are proud of becomes a small book and doesn’t help, again, in a controlled environment with set rules.

Unless a customer looking straight to their eyes and say “You know what, let me speak to your manager” – they haven’t seen customer service at all. If they cannot handle a overweight diner going on and on about a £2 overcooked chips, how exactly are they planning to handle that £2M revenue generating client breathing down their neck? They have a lot to lose, they have spent a fortune (on their passion and certificates/degrees) to get that job. They have to bend at some point because they are more vulnerable and exposed.

The Naturals – Wildlings

Future aspirations always to move up on the ladder to a managerial/leadership role, challenging the status quo with necessary improvements.

Then there’s an interesting third kind, the opportunists, the naturals, the wildlings – one that enjoyed their youth until the mid/late 20s or so. They were confused about what the hell they were supposed to do in life or simply was too busy working on customer facing job to pay the bills in time, assuming that was it. Suddenly one day they found something that they actually love and decided to raise hell by doing something different to make that extra cash and become a software developer (alike) to start with.

The tutorial videos we find in YouTube helped them learn more languages compared to a university degree. Attending those conferences or meetups helped them learn even more in an hour, that they couldn’t have possibly learned in a month by reading a book. Soon they realised that learning a lot is worth fuckall unless they can apply it in practice.

Knowing multiple programming languages may sound impressive but mastering only one of them makes us valuable.

Also they have learned that the above “technical bit” and the “administration bit” complement each other. Both are useless in absence of the other and both needs to work alongside for a successful product/project/business whatever the goal is.

Road to Customer Service

Customer service is something these naturally skilled individuals did everyday since they can remember, it’s their second nature. These personas have knowledge and skills which can rip apart some of the most highly qualified certified professionals, if given a chance. They follow every single word of that Agile Manifesto, which they may not even know is called Agile (to begin with). These candidates are the fastest learners you will ever find in a workplace.

BUT who do these “Naturals” follow and learn from in future? That’s right, most probably from the first 2 types who have already occupied the leadership roles with next to nothing experience on “customer service” in the first place. Back to square one.

Customer Service is about Honesty and Fairness – not bending over when shouted at for money

Honesty is when we convey the truth, doesn’t matter how good or bad it is. Fairness is knowing if we are being transparent and unbiased; and then expecting the same from the end user for their own good. Transparency, accessibility and length of feedback cycle plays a very important role. Just because the end user wants it by next Saturday, doesn’t always mean they have figured it all out. Development work is not as predictable as manufacturing where following a set of precisely designed steps can get to the solution on a predictable date. Development is unpredictable that’s why we need the principles of Agile which can be summarised in the one sentence below:

Being agile needs a swift change in one’s personality:

from knowing how to get shit half done before deadline

to get the most important shit done first, properly.

Stop judging, Start helping

So how do we teach them what customer service is? So far I did manage to judge all the personas above and assumed we only have these 3 kinds. Consider these 3 to be the most popular routes rather than an absolute number of types. However, we have no right to judge anyone of them, as we can barely make a difference by pointing out what is missing in their journey towards agility. Unfortunately, our approaches can be patronising at times as no one likes to hear that then need to improve. For some, whatever we do to help them will never get their attention.

The way I see it is, none of them are perfect and need help to understand what Agile or Lean or XYZ means. There are so many similarities in all type of mindsets, we might as well drop the names and focus on the principles. To do that you need an Agile Coach or some call them Lean Agile Coach or a Scrum Master.

The 3rd kind above, shows the highest potential to become a good Agile Coach due to their “nothing to lose” attitude.

Make 1st Line Support a mandatory role during Probation

We cannot expect any employees to work following Agile principles without giving a formal hands on training, coaching and mentoring. Then making sure they continuously use those lessons in practice in relevant fields. It’s not possible in a controlled environment. If a company paid to make the employees agile in few days, they have been robbed in broad daylight. If our employees are shadowing us they will probably assume we are being agile, as we are good at throwing the A-word now and then.

Making everyone work for a month or so in the 1st line customer support, will expose the new employees to understand the customer needs on that business. Support them and ingrain these basic principles before they actually start working on the relevant teams with relevant skill set. This may sound out awkward but can create a culture which focuses on end users first.

Don’t be Shy, get Help !

To get help in creating an agile mindset in your organisation, find an Agile Coach “per team” (to begin with). Just make sure –

  1. You know why you are hiring them for
  2. Stay out of their ways, as it will most probably won’t be the same as your’s
  3. Listen, listen and listen again.
  4. Agile Coaches need the most support as they have no authority over anything

 

Most Agile Coaches I have come across so far are the mix of all kinds mentioned above and one way or another they live by those principles in their personal lives as well with an aim to be the 3rd kind and stay like that.

If you have hired an Agile Coach as a “Trophy” to show your clients, don’t expect any improvement.

And don’t blame Agile for your own arrogance and bias towards command and control. At first hiring a dedicated Agile Coach per team may seem out of your yearly budget but it is necessary for the longer run (if you really care) as they create lasting changes, which stays when they leave. A true Agile Coach respects the status quo but doesn’t tolerate it. Make sure you understand “Agile” before hiring an Agile Coach unless you will never like what they propose for a change.

 

P.S: Scrum Masters are Agile Coaches. If you don’t agree, you are most probably the above mentioned hard working 1st kind. Open for a debate here.

Gallery

Stop Redesigning the UI – Add/Remove Features instead

We are working on a new Project to redesign the current User Interface (UI)

This is what I hear when someone says a version of the above statement-

1) “We were stupid enough to rush our first project following the management triangle and screwed the business over in the name of Digital Transformation. Now we are covering our own shit by spending more money and sugar coating the phrases around it.”

2) “We built 1000 features few years back, out of which only 15 are being used regularly. We are actually in deep shit in terms of coping with the maintenance cost of the rest. If we delete the rest (which we should), our bosses will bend us over and ride our arse off !”

3) “We are calling it a UI redesign but it really is a disguise to hire more developers to recover from the technical debt we ignored for the past few years.”

4) “We need to look busy as we are permanent middle managements. We need more meetings, whiteboards, sticky notes, sharpies and latest gadgets to save our worthless jobs.”

5) Finally, when a fellow “Consultant” says it, I hear – “We have managed to brainwash the client that they need a platform redesign of existing fully working application (not just UI), so we can place more expensive consultants (who will be paid half the amount as permanent employees btw) for the next few years. We can sell frameworks like Agile/Lean/DevOps and processes like SCRUM, xp, KANBAN (yes, someone actually wrote it to me once; god was feeling helpless). We can then convert them to one of the scaled agile frameworks.”

So I am not a fan of these characters, let’s move on. Although it was necessary to set the tone of this article to get things straight around fake “projects” which could have easily been a few months of lightweight but effective revamp work.

What’s wrong with UI re-designing?

Nothing. It’s always a good idea to present a fresher look to keep our application visually attractive than our competitors. Problem starts when we use it as an excuse to authorise a hefty budget for a spurious “Project” and not an improved “Product”.

It leaves a room for uncertainty and make our lives hell when we come across a surprise, which we were not expecting. Most “UI redesign” I have come across are basically the same application (with exact same features and specifications) from scratch with different technical stack aka a full platform implementation instead. You may have a better experience elsewhere. It just didn’t made sense at the beginning and didn’t created a sense of purpose. Instead it added high volume of unnecessary work in the backlog. Would love to hear a positive story, please share in the comments.

Top Root Causes

Product? What’s that?

It doesn’t always happen on purpose by the agents of “Change Management”. It happens due to a lack of knowledge in applying an approach which is based on empiricism and using a little less common sense. As long as we treat “development” as another standard project in the business, we will come across these issues. There are good agents, although less in number and are helpless as they won’t get the support from the culture.

Thankfully, a majority of thought leaders in our current world has made it very clear that we should focus on a product, dedicate a team towards it, iterate with empirical evidence and don’t work on anything which doesn’t have a purpose of providing value. May be the world is not ready for it, may be we need to let the world learn by it’s own mistake or maybe we can educate them faster instead of becoming their critic.

Here’s a Million, Burn it

Another root cause is having way too much to spend. No one care about a drop of water from an ocean or whatever analogy we use to describe it. That’s why the amount of waste is proportionally high when a company starts “scaling” their products. We don’t need scaling for products, we need descaling. We need iterations in burst mode so we can compare them and choose the one which actually provide some value and throw out the rest without feeling guilty about performing those small experiments.

In majority of companies, a predicted increase in revenue is measured as success.

 

“We need a 18% rise in the revenue next year as we managed to hit our last year’s target of 16.5%. To do that we will authorise a generous £2 Million on a re-design project proposed by the application development department for the existing application” – it is practically nothing in compared to that £100 Million+ profit they made last year.

Prediction is the worst kind of lie, it creates a sense of premature satisfaction.

Shareholders are happy as they have received more than their predicted cut last year and no improvement is required in anything as long as that number always increases according to “prediction”. Employees will be given bonus based on that as well, whether they have done their job or not.

Adding or Removing Features – Where to start?

Eat your own Dog Food – The What?!

If this concept is new to you – Dog food eating is a (well) known self scrutinising timeboxed event where you taste your own medicine and for a moment forget that you are part of the solution provider. The application we are building for someone, we use it in our own work and see how satisfied we are as the real user for a moment. In case the product is unrelated to our daily work, we pretend we are the user for the timebox.

Technically we should always be doing this without considering it as an event. Although I have seen only a handful of companies doing this and embracing the huge benefit around it. It’s not easy. You have to mimic that asshole who always wait for your mistake and resurface from the grave to screw your life around by changing your plan of action for another quarter (or worse, a year). Better be that critic yourself than giving a random opportunist take a ride.

Responding to change Over following a plan !

Identify the change needed before someone else do.

 

Summary of steps:

  1. Plan a half day timebox for this session.
  2. Make sure everyone on the team except the stakeholders join this. This is important – stakeholders will influence your opinion, so excluding them is a necessary step. You ARE the stakeholder in this session and you have to be brutally honest about it. If you don’t want to, don’t participate.
  3. Create a template of activities to plan a basic layout, sort of like a session based exploratory testing protocol (get help from a QA member if necessary). Remember you are the end user of that feature – establish who that feature in intended to, doesn’t have to be of one kind.
  4. Run the session and be a harsh critic of the platform, find anything that annoyed you.
  5. Document everything you felt and found.
  6. Plan few hours with stakeholders now, show them what you have found. Done.

 

From this point onwards, what a stakeholder decides will take effect, of course. But at least you have a much better understanding rather than reading a list of requirement which you always hated for being too vague.

If you are planning to achieve a sense of purpose start “dog food eating”, start analysing your own product, be your harshest critic and hire someone who makes sure the criticism doesn’t stop and call that role – Chief Nagging Officer.

Implement Analytics – as if you are prep’ing for a legal hearing

A Zombie feature don’t need to be loved, it needs to be shot in head on sight.

Analytics should be the simplest way to help a company on taking informed decision about “removing” a zombie feature. We don’t need analytics to add a new feature, addition is purely based on empiricism and can happen anytime. If we have implemented analytics (most does) but haven’t removed a feature based on the data, we are already doing it wrong. The deeper it is ingrained on our platform the better for greater insights. The purpose is simple – “We like to find out what part of the feature/platform is barely (never) used and delete the code to save maintenance cost”. It helps us in reducing technical debt and remove the stress of handling the legacy code.

It’s hard to throw out months of work knowing it is not being used. We can only blame ourselves for not doing enough research before implementation and make it right in the first place. Guess what, it’s never too late.

Adding or Removing Features – Why does it matter the most?

It’s in the name. We either add or we remove. It’s simpler, it’s almost black and white. While we are adding/removing a new/old feature we will always perform some background work on making it compatible with exciting features, redesign the UI in places, refactor the codebase or simply change the way it works or appear.

At the end, the value will be provided no matter what and it won’t become a worthless internal change with no real visibility of a new improvement. It can be a performance improvement which is not visible to naked eyes but an informative slide show can make up for it. There is always some value on everything, selecting the highest value is what matters.

There is a genuine reason a development team don’t get buy in from the stakeholders for removing technical debt. Often the team fail to provide an effective reason or simply fail to explain why it is important over providing a visible value.

New feature can equate to cost on one way or another, directly or indirectly, which is easier to articulate. When we remove a feature we have to heavily base our recommendations on analytics data explained above. It can still be equated to cost but still good luck with explaining why a working but unused feature was built in the first place. Some understands, some don’t. Be brave enough to raise concern but calm down if your job’s in question.

Conclusion

It comes back to the culture aspect, every time. The culture needs to translate these kind of failures as a learning. A zombie feature can use as much as the “resource” needed, as an actively used feature which makes them very expensive in long run. By resource, I mean real resources like storage, supporting work and maintenance costs which are a great form of waste. So focus on adding a new feature in demand or simply remove the one that nobody owns.. just don’t call it UI redesign.

Gallery

Agile – It’s not about delivering working software faster

What is agile? Most cliched answer to this translates to “delivering working software faster”. Because, agile principles clearly states – “Working software is the primary measure of progress”. It doesn’t mention anything about the speed though. In rest of the article, where ever you see “value” translate it to “shed-load of money” if that works for you. It is very important to establish what is the definition of “value” for you, to understand the true meaning of what agility is.

If you buy a new bike or car, it’s performance will always be lower than a well oiled 2year old vehicle with similar specs. Agile teams are like that. The team members can be experienced and brilliant but to really know what part of the product is making the most value, requires investment on thought process. That’s where a Product Owner/Expert comes in with data to prioritise the most valuable work on top of the backlog and own the decision. It’s their job to also convey “why” it is more valuable to the team as well to validate the possibility.

Example Problem Statement

A company hired 10 team members paying £500/day. Screw prioritisation; an expenditure of £5k/day needs to be used up in anyway possible on that 8hrs contracted. Even if that means we make the member work on items no one really give a shit about or have any value. If we focus on priority we will end up wasting 3hrs a day, out of which the members will celebrate a 2hr lunch and will be milking the strategy. How do you propose to handle that?

Solution

Assuming a 20 days working month, paying £5k/day or £100k/month is actually a lot of money to go down the drain, if they work on features no one asked for. The cost can only be justified if they focus on the most valuable item first, instead of an item you may not need for a month. In many cases, as much as 80% work remaining are actually not necessary for early feedback, as the most valuable 20% decides the fate of a product. Work on them first and save your time and money and stop focusing on what the members are doing, as long as they are working on the right thing you require.

Pareto Principle

Does the above solution sounds familiar? Yes, I am referring to the Pareto Principle which is known for a century now. Albeit, saying that 4:1 distribution is “accurate” would be a wrong generalisation as it’s application varies. But it does make a point about how we should approach the product backlog. Empiricism, hence is the only way to go with faster feedback to continuously update the backlog as we know more and more about the product and end user’s expectation.

Source**

 

Working software is mandatory but the trick is to convey the message like this –

Agile is NOT about delivering working software faster, it is about delivering the most valuable software faster.

End Note

Prioritisation is all that matters. If you have adopted “Agile” and still focusing on speed or amount of work for monitoring purpose, then you are doing it wrong. There, Agile defined the way most businesses want to hear. Value can have different definitions for different businesses, “Money” being the most common form, which we should really focus on.

Hope this article makes it clear why “Agile” makes sense in development.

Gallery

Definition of Done (DoD) in XDE Framework

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

Gallery

Interested in DevOps? Try XDE with XP practices

Culture, movement or practice whatever you call it, DevOps is beautiful. It ensures the collaboration and communication of software professionals who usually doesn’t think alike in most organisations – the Development team and the Operations team. DevOps practices advocates automation of the process of software delivery and infrastructure changes to align these two. Scalability, security and organised chaos promotes a distributed decision making culture, exactly what we need for being agile.

So which framework best suits us, while adopting this DevOps culture? In my biased opinion I feel it’s eXtreme Programming (XP). It’s brilliant practices/ideas are often borrowed by other frameworks including the concept of “User Stories”. Since most frameworks doesn’t specify these practices, most professionals include XP principles (e.g. TDD, pair programming) anyway. Reason why XP, as a methodology, is underrated and overshadowed by other popular frameworks quite heavily.

Xtreme Decoupled Engineering (XDE) framework compliments XP, by adding the concept of decoupled processes and making sure DevOps adoption doesn’t stay just a great idea but is also implemented to save the world 😉

Individuals and interactions OVER processes and tools

“Over” is often read as “Not” by a majority of Agile adopters, who finally starts to realise why agility is far better than many traditional techniques. Is it their mistake? Of course not. Agile Manifesto is quite philosophical and the inclusion of “over” just assumes that the reader won’t translate it to suit their needs. It’s either this or that, not both. If both then to what extent? No one have a definite answer, as it was meant to help evolution which is the beauty of the agile manifesto. But it does scare the organisation trying to transition as not all organisations are consultancies. Not everyone is working for a “client”. Sometimes stability is more important to measure few aspects of the transition. This stability and standardisation of processes is necessary to some extent, as long as it’s not blocking the product development.

No doubt, Individuals and Interactions are important, but it can’t work on it’s own without processes and practices to support the outcome. We need a basic level of standardised processes and practices to accompany this vision of adopting devops to become agile. In fact, most frameworks have vague undocumented processes which are not standardised for all teams. It is extremely unsettling for organisations who are paranoid to begin with. If documented, they are extremely ambiguous, hence often misinterpreted (ref. 1, 2, 3).

XDE complimenting XP – Closing the gaps

I have never seen XP work within immature teams because it needs a sense of responsibility and the urge to know WHY, which only comes from experience. If we ask an immature team to follow XP, they usually try Scrum instead and include TDD and pair programming to call it XP. Mostly because Scrum has a guide which they can refer back to. But there are some subtle differences between XP and Scrum, as documented by Mike Cohn.

When we realise most frameworks are ambiguous about implementing set processes, we often fill in the gaps to support the agile principles ourselves. But during this we may end up in a process which can do more harm than good. By leaving a gap we are letting our mind wander. Most professionals look for the processes first and then learn the principles behind it. Some never care to learn the principles at all, as they assume implementing a framework takes care of everything.

This blind faith and incomplete knowledge promotes half baked assumption of knowing what works and what doesn’t. First we should go by book and then we should focus on mastering it or even bending the rules. XDE tries to close these gaps by formalising the Definition of Done and support to DevOps mindset while advocating the best practices from XP.

Companies trying to adopt DevOps needs a framework which have a set of processes for all teams; is predictable yet highly customisable.

XDE provides that skeleton by defining the start and end of the development lifecycle within the bubble. “Done” for a product increment is defined to include End user feedback – Continuous Delivery plus at least some feedback from users before starting the next work item. It creates a transparent environment of keeping the road map visible at all time by focusing on the value to the end user.

To assure that the Bubble doesn’t start working on the next item in the backlog, XDE introduces One Rule (1R) which creates a process of working on one at a time and only focus on outcome not output.

One Rule (1R) makes sure we are focused on Outcome not Output.

Decouple Processes and Succeed

As we know XDE doesn’t proposes any practices on how the product is built but it recommends XP principles. XP principles with it’s test first approach suits the best but needs a robust stabilising skeleton which XDE provides – hence compliments each other. While the 1R team members work following the One Rule, if a team member is free doing nothing (as they are not allowed to work on anything else) they have no choice but to focus on the ongoing work.

  • “Are you free? Great, get the chair and let’s pair for the rest of the day.”
  • “Yoda is off sick today and we need to review the unit tests before he can start implementing the code tomorrow. Can you do it while you wait?”

Therefore, XDE helps organisation to adopt devops mindset smoothly with the least friction possible and XP assures that the quality of the delivery is spot on and ready for feedback. Try XDE along with XP to initiate the DevOps mindset and help your organisation is agile transformation. Focus on outcome not output.

Gallery

Test Automation is Dead, Period.

This article is aimed to all software test professionals who are working as or planning to pursue a career as Automation Test Engineer/SDET/SDITs in future. If the organisation we are working for is trying to be agile, these test professionals can make an enormous contribution by “directing” the development and not just being a silo of knowledge on a specialised department. So focus and read this very carefully as this will make you the legend you can be, before learning something which is dying or is already dead in agile development.

Simplest definition of test automation is provided in wiki –

Test automation is the use of special software to control the execution of tests and the comparison of actual outcomes with predicted outcomes.

 

“Special Software” – this is your hint. An automation testing framework is exactly that, which is maintained side by side. In many cases, it has an entirely different code base; responsibility of which falls on the shoulders of specialist Automated Testers. I have been there myself. While working as a Software Developer in Test, I used to create frameworks from scratch and maintain. Doesn’t matter what programming language the application is written on, these frameworks can “test” every bloody functionality on the application under test, brilliant stuff. UI, API or Integration you name it, we used to have solutions for everything. Reason why I have enormous respect towards the Testing Community. Only problem was, we were testing AFTER the product was built. Here’s why it didn’t made sense.

Someone gave me a piece of advice years back – “Don’t call it wrong, call it different”. My reaction was neutral, even though I completely disagree, as the person had like 20 years of experience. In fact, I thought I learned something “valuable” that day from a very experienced professional. Few months later, both of us shared an awkward glance, which to some extent proved that I didn’t learned anything valuable and was simply fooled to believe so. That “calling different” attitude became an impediment on an ongoing project as it needed urgent rescue and we realised we should have called it “wrong” and made it right.. sad times.

 

My point is, we have to call it wrong when it is; unless you can never initiate the process of correcting it. Calling it “different” is bureaucratic encouragement to keep doing whatever we are doing and screwing the organisation we are working for, sometimes unconsciously. Let’s come to the subject which needs help, by not being called as different/wrong but being surgically removed – Test Automation. It might be right in a distant past, may be for some, which I have never seen producing real value so will trust and respect the past decisions.

Ask any software test professional “What is your test coverage like?”. You will usually get a reply with a number or percent. You can easily assume they have an Automated Testing Framework to check if the tests are passing, after a product is build/changed. These tests reduces the manual effort while regression testing (mostly functional tests) and saves valuable time before the release deadline. Isn’t it? Proud organisations share these metrics often by saying “we have X% test coverage which is way better than market standard of Y%”.

Now, here are some words/phrases mentioned in the above paragraph, which we should pay attention and understand why they smell.

Testing after the product has been build/changed

If we are testing after a product is built, we are –

Simply validating what it does, not what it should do.

If we don’t want a baby, we use a condom. We don’t have sex anyway and pray that she will not get pregnant; well unless you forget to buy one. Prevention is always advised over “dealing with the consequences” later on, doesn’t matter if it’s your sex life or delivering a software. Have protected sex and stop worrying about raising an “unwanted” baby or even worse consequences. The tests should be our condoms which we put in place before building a product to establish a predictable outcome. Try using this example at your work. If you get a mail from your HR then I am not responsible but feel free to blame it on me. Use weird analogies like this to make a point, people usually remember them for a long time.

Regression testing before the release deadline

Admit it, it’s the truth. In fact, I have seen many teams doing a ceremonial regression testing before a release date. They still does regression testing even if they have automated test coverage (god I hate the term) of 85-90%. Guess what, they still have missed critical bugs. When asked, the usual reply was “it was an edge case which wasn’t covered in our automated testing framework. We will include the test before the next production deploy, promise”.

So do we do regression testing in targeted areas, as in risk based testing? Yes we can, but then we might miss several other areas which “we think” is not risky. We can never win as there will always be bugs.

As long as those bugs are not failed acceptance criteria, they will be treated as learning rather than fails.

The trick to improve is to run regression test while doing continuous integration as part of the same code base. If it fails, fix and re-run as explained in the XP best practices. At least it is failing on your CI environment not in production. Regression testing should happen every time there is a change, doesn’t matter how small the change is. It should happen as early as possible and should never be treated as a ceremony.

Exploratory Testing, therefore, should be the only activity after a product is deployed to find edge cases and that’s why manual testing can never be dead.

Test automation, therefore, might reduce your manual effort but you are still managing and troubleshooting a separate framework and wasting enormous amount of time and effort to prove something which is already given. It is still not “defining” what the product should do.

Test Coverage fallacy

Quality assurance starts before the software is built. Fact is, it never assures the quality if you are writing tests after and it simply becomes an activity of executing the tests. So burn that test coverage report as it only proves that the work is done. It never says how it assures the quality.

Another aspect of “doing it right for wrong reasons” is unit testing in TDD. A good amount of software development professionals and higher management uses the % “test” coverage at unit level in their metrics to prove the hard work done to assure quality. You might know where I am going with this. If you are doing a Test Driven Development (TDD) you are NOT testing anything that matters to the end users, so stop adding the number of unit tests in your test coverage report.

TDD is for architecture and is a brilliant method to create a robust solution which supports the functionalities on top of it. The unit tests are merely the by-products of a good design and does not guarantee the complete functional behaviours. TDD is always recommended but don’t try to make it sound like it’s testing the acceptance criterion. In fact, a good programmer writes these unit tests to be confident in his own coding skills not because someone ask them to do it. In most cases, TDD is enforced to reduce technical debt by creating a culture of continuous refactoring.

Third aspect of the coverage fallacy is, coverage doesn’t mean it is always fully automated. It can be half manual and half automated. Coverage simply means we are confident about the % number of the functionalities and the rest are not tested. This creates a sense of false security. We should always test everything and we can only do it when we direct what we are building. If exploratory testing finds an edge case then we can add a direction to tackle the behaviour and not write to test to run for later. Regression testing after the changes are in place is considered already late. If you are an experienced testers you might read the code changes and figure out what areas have no affect by the change and decide to leave it, but you are still late.

Use your expertise BEFORE the development – Acceptance Guides not Tests

So what about you planned career as a Test Automation engineer? Well, no one said your skills are worthless, in fact you can use more of it.

We just have to shift left, a bit more left than we initially expected.

Not only we have to stop writing automated tests, we write them as guides before we decide to start working on the work item. So the programmers now have to implement the minimal code to pass your statement, hence preventing the defects for you. Better if you can help them in a pair programming session. Being said that, it doesn’t mean that we cannot apply the principles behind TDD. Enter Acceptance Test Driven Development (ATDD), Continuous Integration and Continuous Delivery.

Assuming that everyone have heard/read about these; if not there are a huge collection of online materials to read. In a nutshell, ATDD advocates that we should write acceptance tests before writing the code for the software we build. It defines what we should make with minimal codes to pass these tests, just like TDD but in a higher level which the end users are expecting to work.

Are these acceptance tests really tests though?

Yes and No. These are not tests but are called as one in my opinion (topic of a debate?). Enlighten me if you know. Instead these are expected results (or behaviours) which are used as guides to develop a piece of functionality. Therefore, we should really be calling them “Acceptance Guides” (just a thought). Reason why a lot of us use behaviours as proposed in BDD, as they kind of compliment each other. These can include non-functional tests as well.

 

Verdict

Therefore, to summarise, we are talking about removing regression tests completely after development while including them within the same code base as acceptance tests/guides (doesn’t matter what it’s called at this moment). Also, we need to remove unit tests as a data to include within a Test Coverage metrics. Behold, we have just proved Test Automation can be dead or is already dead.

Be Lean to stay agile.

Gallery

Agile Transformation – Does it have to be Disruptive?

Agile transformation is the new “thing”, most software delivery businesses are trying to get a grip on. There’s a divide in opinion, facts and politics around it. Many running after the “credit” they get in changing a thing or two to get their names in the list of contributors, which may be soon converted into a tombstone. Others are combining the best practices, changing processes overnight and rebuilding culture to support the sudden changes. Everyone wants a piece of the action but the grave consequences are affecting the business they represent. Why? Because everyone expects it to happen faster, disruptive and trying to change things overnight which wasn’t changed for decades.

Unfortunately the message delivered to them reads like this – “Move into agile methods and you can get more products delivered in the same time”.

 

The most underrated fact around these, when we talk about “Agile” is –

“Agile methods will not double your productivity, in fact it will slow you down to begin with. Agile principles are about providing the sense of creating the most valuable product first.”

The above fact is ignored a lot of time and rouge consultants starts selling “Agile” promising more productivity in compared to Waterfall. Terms get thrown from all sides to the person responsible for budget and a chain of middle management roles wait patiently to get a cut. Members who are not supporting the “movement” either receives a calendar invite from HR or get clinically radicalised to the new religion “Agile”. Why are we trying to do Agile? No idea.

Disruption = Difference in Opinion

 

.If this difference in opinion is not resolved, you can never become agile as it depends on the organisation maturity in every aspect. Reason why many of us heard the phrase “Culture change” thrown at us during an agile transformation. A new bread of management leads the bandwagon towards a belief that doing agile will resolve all problems, improve output and finish project early. But here’s a subtle difference which establishes the Value to the business –

Output ≠ Outcome

 

Outcome may or may not be an intended feature, it can be a lesson which we learn from a failure in an iteration. Some might wonder – “What’s the value of this lesson from a failure which is not generating any revenue?” Well, as an example, a failure can teach us how ridiculous a feature is to begin with, so we don’t invest in future iterations of the feature. Hence reducing the risk of creating a worthless product based on the failed iteration which can be a short term success and a long term burden for a business.

Agile transformation, hence, should reflect a sense of purpose of what we are doing and WHY we have to do it. If, as an organisation we are unable to share the big picture to all employees, there is no way we can be agile in a distant future. Agility is not about implementing a framework or method or tool in place and hope for the best. It’s about self evaluation as a company to learn what we can or cannot do, accepting the limits and exposing the barriers which stops us from being agile. We execute, learn and improve.

The best agile transformations are gradual, slow and have a good amount of time invested in learning while we try to move away from the traditional approaches.

On the Contrary, there are exceptions where Disruption is the Only way!

Gradual improvements are welcome where there is no need for drastic change. But in some organisations this empathetic mindset can be taken for granted. We will find personalities who are extremely qualified and have a very good knowledge of what is right. But milking it seems a better idea for them rather than improvements while exploiting the same knowledge of agile transformation. This is especially true if they are not a “Permy”, as their political existence is based on how long they can stretch the project to get maximum benefit out of a contract/temporary role.

I would be wrong, if I say all contractors are like this. Of course not. In fact, most team level contractors are exceptionally brilliant and embrace agility. The issue starts when we have the middle management as a contractor, who can influence crucial business decisions. These personalities will not harm the business but won’t improve it either. They will keep it as it is and in the name of “Agile Transformation” the project can last for years to come.

Agile Transformation doesn’t happen in a quarter, but it shouldn’t take over a year either.

 

If it takes more than a year with low or no relevant value delivered, we can be dead sure that it is being prevented by a crucial impediment, a process or a personality on power. It can be anything. A year long transformation should be a warning that, not everyone is on board. In these situations, empathy should be shown to personalities who are on board and the rest should be disrupted to make a crucial business decision.

Do you feel the same way?

Which version of the transformation have you experienced/experiencing? Would love to hear your thoughts on this.