4 Dimensions of Agile

 This is the weekend read result of  Clean Agile : Back to Basics of Uncle Bob (Robert  Martin.   It is kind of an  amazing biography of software practices in the last 20 years  (and may be beyond).  

They  most companies are using agile is by jailing the spirit behind it.  Instead of talking more of how we are failing, I can focus on what my perspective of agile process based on the book reading as well as experiences and other reads.

Agile has  4 different dimensions.

• Business
• Developers
• Collaboration
• Managers 

First some basics

The Manifestos

Agile Manifesto

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan


That is, while there is value in the items on
the right, we value the items on the left more.

Software Craftsmanship  Manifesto

As aspiring Software Craftsmen we are raising the bar of  professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

         Not only working software,
                         but also well-crafted software

         Not only responding to change,
                         but also steadily adding value

         Not only individuals and interactions,
                         but also a community of professionals

         Not only customer collaboration,
                         but also productive partnerships

That is, in pursuit of the items on the left we have found
the items on the right to be indispensable.

Business

Often this is treated as the full agile process. How requirements are defined, nurtured and handed over to developers, how they are estimated, assigned and forced to meet timelines etc. We can talk about for ever on various things that we don't do right, but instead lets just focus on the right things.

Avoiding the standard jargons like Scrum or sprint etc for simplicity and to avoid misconceptions. 

Guidelines

• Openness
• DO NOT force.
• 
  

Backlog grooming and prioritization 

Product Owner/Specialist/Manager(s) need to continuously groom the backlog.

• Customer inputs, not necessarily all what customer x wants but digest their wants and make a needy list.
• Product vision - based on the bigger vision, add missing parts or improve current ones. 
• Support tickets -  based on short comings of current system, customer tickets speak a ton about it.
• Technical backlog - did we compromise something in the past? address it before it becomes  unmanageable.
• Prioritization is not only product owner thing. its whole team thing.  Its not that team will pick up from the top and do best, some things may  be linked and need to be done in order (most often this is the case). So whole team need to participate in this, this can happen in pre planning meetings.

Organizing recurring meetings with closed few on this could be a good way to go about reviewing them internally. Product Manager,  team leads and occasionally  developers as needed.

Pre planning

It is important for to organize a pre planning meeting with  the team before actual planning. Let team have time to think of the backlog items, ask questions, seek clarifications and at the end digest them a bit more.  This also gives opportunity for  product owner to fine tune the scope and add missing details. Pre planning should happen few days before the actual planning meeting. 

Planning

Planning is important and doing it in the right way is important. For each iteration, all team meets and 

• Product Owner reviews each ticket. goes through details. 
• Team members are going to estimate together and go with majority decision. Product Owner or Manager or CEO SHOULD NOT set ETA and ask them to estimate. 
• Team members get to chose who want to work on this ticket. (Manager SHOULD NOT assign tickets).

Mid Review

For each iteration, the team should meet in the middle to see how its going so far and if any additional changes needed.

Completion

Focus should be completing all or some tasks in their entirety. If there are 5 tasks, instead of finishing 5 of them at 80%, it is better to finish 3 or 4 at 100% and  push one to the future iteration.

Estimations

Estimation technique is important,  story points seems to be relatively better option.  It would take few iterations to come to standardization of estimation.  Long term goal is to have a constant velocity leading to 0 acceleration. story point inflation is bad and inadvertently managers may force team to inflate to show progress.  If there is a task X,  ideally it should be estimated same now or after few months/years, if this value changes depending on when you do it and if thats because of expectations on high productivity from  manager, it's a serious concern.

Definition of Done

Definition of done is nothing but to meet all of the "acceptance criteria" on the built solution.  Defining acceptance criteria is super important for the product owner and the team (if technical conditions to be added). When the acceptance criteria matches

Demo

Product Owner or QA should be able to demonstrate the completed stories.  if it's too technical, developers can do the demo. But every iteration should have demo.

Deployable at every iteration

The product / solution should be deployable at the end of each iteration. It could be more frequent on demand, but maximum delayed deployments can be once per iteration.

Developers

Collective Ownership

No one owns the code in agile project. the code is owned by the team as a whole.

Test Driven Development -TDD

• Do not write any production code until you have first written a test that fails due to the lack of that code.
• Do not write more of a test than is sufficient to fail - and failing to compile counts as a failure.
• Do not write more production code than is sufficient to pass the currently failing test.

While it is hard to start practicing TDD,  it is more FUN when we do.   Most difficulties for TDD are:

• Delayed scoping on the tickets by Product Owner.
• Pressure cooker situation by Manager to deliver.
• Lack of motivation

Building code and then tests makes building tests makes it a boring job.  Conversely building tests first and then building feature makes it a fun activity and sense of achievement every day. 

Continuous Integration

All feature code branches need to be tested for all unit and acceptance tests passed and merged with master/release branch.  Code should be deployable to production all the time for the master/release branch. Any changes that should not be active when deployed are to be dealt with using toggles/feature flags.

Continuous Builds and any broken build should mean, the developers stop everything they are doing and fix the build.

Debugging

If you are spending to much debugging to fix bugs, it may mean the tests seem to be not good enough.  Too much of debugging skills may indirectly mean that there are not enough tests :-). 

Simple Design

When code is hard to add test cases, it just means it is not designed correct.  writing tests can not be after thought. 

Design is a continuous process. if there comes a situation where "that is not possible with current design" situation, it is a problem with design.

Courage

There should be no fear reaction.  You  should not fear the code.  There should be no fear to touch code. There should be no fear to clean the code. 

Pair programming

Respect Technical backlog

Take Code Reviews Seriously.

QA should be part of the team

Collaboration

A team member need to collaborate with many others outside the team.  A developer may be part of multiple teams/iterations, product owner need to coordinate and meet other product owners, managers may need to collaborate with other managers,  team QA may need to interact with other teams QA engineers and so on.  we need to make sure we have all of this factored into practice. 

Managers

If there is single biggest barrier for agile implementation, it is managers at various levels and forms but most probably the middle management of large companies. Managers want to build team of mercenaries who follow orders. Bigger problem is formal acceptance and informally do everything against it.   Primary reason being feeling of losing control.  Lets look at reasons why managers want to agree with new initiatives.

Major reasons for accepting the agile initiatives

•  They don't want to say No to upper management. (We are trained to say Yes, its hard earned skill).
• They want to sound positive.
• They really don't know
• They know they can always tweak the way they want it(process) to be. 

Major reasons not truly accepting the agile initiative

(or accepting the decision to go agile but why not support actual execution)

• Fear of losing control.
• Inability to accept No.
• Aversion to change
• Experience or stories heard else where of failed agile implementation
• Failure to realize  "adding staff" is not a solution.

The fact  success of agile really helps managers achieve their goal of running successful business is not often understood.  Manager role is not about being lazy but keeping team busy.

Why agile fails

Agile implementations are seen pretty successful in small to medium size organizations while it's hard to claim success with large organizations with legacy softwares and mindset.  Primary reasons being

• Its old wine in new bottle mindset. Mostly from mid management of the company. We pretend accepting the new but struck with old mindset.
• Fear of adopting to new changes. we do not know what happens to my role/identity and authority.
• Willfully under resourcing the agile teams. Each development team needs set of developers and QA and full attention of the product owner etc If we do not have PO or QAs in the team, it doesn't help. 
• Input anemia. If product team doesn't commit and gives only minimal details and expects developers to fill in the blanks and major chunk of it. 
• QA need to part of the team and not outside of it.
• Managers need to be open to learn  accepting No, 
• Agile is used as a weapon to keep developers busy all the time with no visible benefit to product/company, it is used as a tool by managers.

when we look at how various designs of every day life, it is so amazing,  Electrician , plumber or a civil engineer designs are amazing, they built amazing tools and use in the right way.  When it comes to softwares a wrong implementation of a right tool is like  perpetual labor pains (having labor pains but not actually delivering, and at times we put the teams on anesthesia and pretending everything is ok).

Success Result

• Everyone have work life balance. There is family for everyone and we are not in jail term. 
• Clean code with continuous CI/CD
• Open for change, ideas. 
• We are not building something someone else next year calling it as "legacy" and need for redesign/build.
• Happy customer, he has a voice and someone actually is looking at and acting on.
• Truly flat productivity  (no acceleration or most importantly no deceleration)

Summary

Biggest misconception  about going agile is how it is perceived to be a common understanding of agile from the business dimension and thinking thats all is needed.  The Other 3 dimensions are not given right amount of importance.   It is not that we do not have other dimensions understood at all, but not organized or understood correctly or staffed correctly resulting failure and may cause "I told you so" situation.  

It is the "acceptance" for change and having "enough" of everything, including  staffing as needed, providing the tools and support and accepting from the top to bottom of the company for agile is what makes it successful. Managers can provide a transparant continuous watch dog role and be happy that teams are delivering without much of them doing micro management.