Better product by documenting trust boundary

Have you ever faced issue when you trusted system, team or product and that resulted in failure of feature or system?




In fast changing progressive delivery, definition of trust keeps on changing. Some of the trust issues that happens are.

• Other system sends junk data.
• Other system does not maintain constraint of data like unique , null , referential integrity.
• Third party library causing unknown side effect.
• Nitpicking user or QA.
• Ignorant users.
• Demanding product owner.

As engineer you have to continuously revisit trust boundary otherwise someone else will find gap and exploit system. Trust issues happens between teams or within single team, so it is important to establish trust boundary to smooth function of teams. 

Knowledge gaps plays big role in trust assumption that teams or individual make, best way of preventing trust issues are to document it as group that includes developers , QA and business. Once line is drawn then it becomes easy to take decision on different part of system.

The best part of agreeing on trust boundary is that it gives common framework for discussion and also avoids unproductive discussion.

So next time before starting to build any new feature or system , list down how much you trust other system or teams. Create triggers or alerts for every trust boundary violations ,so that you can react when something unexpected happens.

Bugs report also has lots of clue about trust boundary violation, so before fixing it revisit the trust boundary and make adjustment. 

Tracer bullet software development

Software development methodology is evolving very fast and every team has found version that works well in current context.

Software development methodology is going through continuous improvement.

The_Pragmatic_Programmer book talks about Trace bullet approach and as per that it comes down to feedback. The more quickly you get feedback, less change is required to hit the target.

I have used Tracer Bullet approach through out my career with good success.

I will share another approach or mindset of software development that can be used in some scenario to build better product and create value.

Explore or Discovery 


Many time as team you have to find what is the next feature you should be building that will help in increasing adoption of product.
So i call this as Explore or Discover phase and this phase of development has very different goal and trade off. This phase means that you have to move fast, cut some corners to get feedback. This phase will not have enough tests, documentation, code quality is not good etc.

Important thing about this phase is you are actively collecting feedback on whether this is the next big idea your team will be investing.
In this phase you have to make sure you gain more than loose, so timebox discovery phase to keep track on resource that is consumed.

Outcome of successful discovery puts you in Growth phase and in many case this will be steep growth, but every unsuccessful outcome has lots of signal on next exploration.

 You Build to learn in this phase and once you learned then move to next phase or start another discovery.

Growth Phase


This phase is outcome of successful discovery and now you have found the next feature that market or your target audience need.
Trade off for this phase is very different from Explore phase, you have to stabilized feature , do changes based on feedback so users who have shown interest in idea are still engaged. Users who got on-boarded work like your sponsor, so keep them in loop.

Interesting things about this phase is your team will be in war room type of situation, everyone is trying to get over huddles and get feature out.

Word of caution this phase very intense and demanding. This phase is the real "Sprint" phase not the agile sprint! putting extra hours has good returns.
Another thing to watch out is to be persistent in exploiting maximum of new feature but many time team drops the ball and go back to discovery phase. 

I would say this phase also puts design pressure on team and you can refer to design-pressure-on-engineering-team post that talks about it.

Successful outcome of this phase is Expand phase. Team is exhausted after this phase but very motivated.

Expand Phase


Welcome to phase that requires building software in the way we learn in text book, this is the phase where engineering discipline are very important because solution has to be scalable, maintainable , reliable etc.
Now you can go to management and ask for more funds to get servers , expand team etc because this idea will generate some profit.

Don't build product like discovery phase in this stage otherwise you will become victim of your own success, below image should be good example of it.



Conclusion
All of these phases has very different constraint and trade off and it is very important to know that, expand phase can't be managed like explore phase or vise versa and i have also found that engineering disciplined are very very different in these phase, so you need team that is aligned with mindset. If you get your team wrong then it can really very challenging to execute phase.

It is fascinating to see that our industry keeps on evolving and new development methodology are found.

It is much more than Agile or scrum.

I want to end with quote
As engineering team we should do continuous exploration and exploration is not linear process.

Some of other post on software development that you might interesting

need-driven-software-development-using
broken-promise-of-agile
cargo-cult-innovation-center

I will be happy to learn about new ways of building software, so please share it!

If you like the post then you can follow me on twitter.

Broken promise of Agile

AgileManifesto was written 17 years back(i.e 2001) and is it able to bring the change to industry ?



I would say yes but not is the way authors wanted.

Many consulting company made millions of $ but as software engineer i did not see the change.

How did Agile broke promise

I will put key things that authors wanted so we have some context to discuss about this

Individuals and interactions over processes and tools
Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

This looks so good :-)

Lets start with education industry

"Attend Agile training for 2 days and you are certified Scrum master or Agile Developer"

What did people learn after these workshop ? Standup, Planning Poker, retrospective , backlog grooming , JIRA and many more things.

One thing that is missing is "Agile mindset" , no one can teach or learn this in 2 days so it is big joke that you team went to expensive training and they are Agile Team.

Lets go over main items so see how industry see main goals of Agile

• Individuals and interactions over processes and tools

Almost all the team got this wrong, they thought we need more tools JIRA was born, industry created big ceremony(backklog groming, standup, reto etc)
I think have too many things in JIRA tell only one thing that software quality is bad or team is too slow to delivery features or product team is creating shopping list of features that they never wanted.

Now it has gone to extend that you need multiple product owner for just grooming session and scrum masters for running retrospective meeting and to add more project manager to track story points/burn down etc.

Team is spending more time on Jira board rather than talking to team. We killed individual& interactions .

How many tools or process we added ? it is count less .

• Working software over comprehensive documentation

People got confused with this and they said i need working software + document. Now nothing got done properly and some team will come and say we are AgileWater it mean we build software fast but also use documents that is required for waterfall.
Developer endup doing more non productive work.

Working Software was also take as team is allowed to release crap in production because we are Agile.
What was meant by working software was MVP not 20% or 40% developed item, feature is done or not done there is nothing like 50% when that feature is released to production.

Team is put in so much pressure to release that they end up taking shortcut and to address that "Tech Debt" drive is required.

When software team goes to product to get fund/approval to fix all the Tech Debt then team comes and say why did you develop & deploy crap piece of software.

• Customer collaboration over contract negotiation

This is classic customer used Agile for blackmailing or question team credential to put last minute change. This gives them licences to change the requirement any time.
Not to miss commitment that is taken inform of Story Points and if team miss that then it is expected that they need to put extra hours.

Dev team is not different they use this as excuse to build  bad quality of software.

• Responding to change over following a plan

Agile never said that build feature without tests, architecture or no plan.
Planning is must and good architecture also but it should be Just enough to move in right direction and it is continuous architecture without end state.

Team took this like no design or architecture to response to change.

Conclusion

One of my favorite questions about sprint is

"How long is your sprint ?"
 2/3 weeks ?

"Why 2 weeks , why not 1 month or 1 year ? who decided this ?"
It is written in Agile manifesto or my manager told this or i don't know other teams are doing this .

"How long ticket sits in backlog before making to production ?"
I don't know . Check with my TPM or if some one knows they will come and tell 1 year or 3 year"


Agile was about giving team freedom to choose sprint size based on when they are ready for feedback or customer is ready to give feedback
Sprint can 1 week or 6 months but key point is you should get the feedback after that and adjust.
If customer are not in the feedback loop then go back to waterfall .

Another thing was about Software Craftmanship.
Agile project has so many non developer like Project manager, Project manager, Scrum Master, Agile coach that they don't value Craftmanship , so we developer start new conference on this and get more disconnected.

Agile was written by developer for developer but now we are out and this place is taking by non-developers .

In Agile Conference ask the question "how many developer? "
You will see less hands :-( because they are in other craftman conference.

Agile project are about project management, dates, money , time.
Manager makes sure that plan is made by them and followed by team.

Today all project are agile but they still fail, over budget, never on time.

Any process like Agile has one hidden feedback that is called "Dissatisfaction" and you need respond to that change to become better.

Our Software industry has three inevitable things
 - Degradation
 - Dysfunction
 - Expiry

Degradation ->  Maintaining,Transformation
Dysfunction -> Innovation & Challenge
Expiry  -> Creating & Starting over

Degradation ,Dysfunction & Expiry applies to people, project, team,process , strategy , organization.

Agile is no different identify the phase and create version 2 of process or find new one that works.

Pragmatic Programmer - Boiled frog.

 Pragmatic Programmer book has lots of solid advice and it was published 18(1999) years ago and all that advice is still relevant.

It has one section on Stone Soup & Boiled frogs.

Boiled frogs

This theory is not tested but it is said that if you take frog and drop it into boiling water, it will jump out of it but if you place frog in pan of clod water, then gradually heat it, the frog won't notice and slow increase in temperature will be not noticed by frog and it will be cooked.

Stone Soup

3 soldiers returning home after war were hungry. When they saw the village ahead their spirits lifted they were sure that people will give them food. But doors were locked and windows were closed. After many years of war, the villagers were short on food and hoarded what they had.

The soldiers boiled a pot of water and carefully placed three stones into it. The amazed villager came out to know more about it.

Soldiers explained that this is "Stone Soup" and went to to add "although some say that it tastes even better with few carrots"

Villagers ran off and got basket of carrots and asked "is that ok ?"

"Well" said the soldiers "a couple of potatoes give it body"

Another villager ran and got some potatoes and each of villager slowly taking stuff out and eventually they had produced large pot of steaming soup.

Soldiers removed stone and sat with villager and everybody enjoyed meal.

What do we learn ?

Stone soup tells that you need act as catalyst to bring the people together so that they can jointly produced something that could not have done themselves and eventually every one wins.

Does this sound like issues that we face every day to get work done in team ?

This mindset is called "start-up fatigue"

If you are stuck in getting you idea then take out stones, build something small but well enough to say "it would be better if we add..........." and pretend it is not important.

Sit back and wait for them to start asking for the stuff you originally wanted. 

People find it easy to join to the ongoing success :-)

Lets look at frog story.

Don't be frog, keep eye on the changes happening around you , in your team, company, industry.

Constantly review what is happening and take some action.

Don't become frog, tech world is changing fast, new skills are required, new approach is required , new tools, lot of un-learning is required to learn something new.

Frog will not noticed change, if you don't want to frog then learn to embrace the change.

Moral of story is 

Be a catalyst for change
Remember the Big Picture

Read Pragmatic-Programmer-Journeyman-Master book if you have not read it.

Joy Inc is really Joyful

I heard closing keynote talk by Richard-Sheridan at agile singapore conference where he shared how he build joyful company.

Richard has published book Joy, Inc.: How We Built a Workplace People Love to share his experience of building amazing organization.

I got copy of book few days back and started reading it, it is very difficult to put it down once you pick it up.
I have read few chapters in last 2 days and want to share few things that i liked .

Book starts with "Let's try something new, let't run an experiment", this is very good approach to plant seed for change.

Tangible Joy
Book define tangible joy as "delivering a product or service to world that's so enjoyed , in fact , that people stop you on the street and say,"really, you did that ? i love it"

By reading this i realized that how crappy product i have build :-(

Stupid Users
It has section on stupid user and context it that software industry think users are stupid and they need Dummies book to help them successfully use our beautifully designed technology because they are dump and don't understand our master piece.

Joy will lift you and your team
He gives reason why Wright brothers were able to fly and Samuel Pierpont Langley was not

Langley was trying to build an airplan. The Wright brothers wanted to fly.

This is so much applicable to our industry, we are so much after bleeding edge technology that we forget the real problem that is supposed to be solved by technology

Lots of experiment
This book is full of experiment he did to build Joy Inc.

Pair Programming
Everybody knows benefit of pairing but still many organization are reluctant to try

Wide Open space
Wide open space with no office,cubes is very good for collaborative work, but organization has Cube culture and with every promotion individual moves away from team and get locked in private office.

Rewards System
With culture change rewards system should also change , but most of the organization never change rewards system.
I think this is one of the main topic of book, few things mention in book are.

 Now you have fair idea about what rewards system should look like

Risk of staying same
This was eye opening "The risk of staying the same had been far greater than the risk of change"

Big-Dog Discussion
Big dogs in organization are special people and by looking at them voice echos in your ear
"You don't matter as much as I do"
@menlo big decision are not made in close door conference room so that people don't feel that they are not important.

Tower of knowledge
Book as very nice section about "Mr Dave" - person on team who has vast technical knowledge that no one else have.
This is such a common problem and most of the organization falls in this trap and it is very common in Banks.
Dave is bottleneck of entire organization or department and he can't go on vacation!
Pair programming is the recommended solution for Dave and organization


Books has lots of practical advise, i highly recommend this book.

Some talks/podcast by Richard
A CEO’S JOURNEY TO CREATING A CULTURE WHERE PEOPLE CAN THRIVE
Joy, Inc. | Rich Sheridan