How to screw-up a software project - a few quick tips

Inspired by the brilliant book by Paul Watzlawick "The Situation Is Hopeless But Not Serious (The Pursuit of Unhappiness)" I would like to share with you some tips on how to be inefficient with your software projects. We all dwell continuously on what to do so as to finalize projects on time and within budget or succeed with a software product rollout. That's well and good but I guess at least some of you got bored of all of that and wonder what path one should follow to screw-up things badly. Be blessed all of you! and read here my few tips that will surely bring about disaster:

1) Fill in your teams with contractors exclusively but beware of hiring teams! The people you hire must not have ever worked with each other. Sit then back relaxed and wait for results. A bunch of individuals who don't feel connected to your company will spend hours on deciding upon who's smarter than other or on producing just for the sake of sheer production. Be sure outstanding results are guaranteed!

2) Stay away from any silly thoughts that good engineering skills, team building and a decentralised process that lets people sort out the details comes in handy. Instead, follow the rule which made successful projects possible. Namely: there is nothing better than a step by step deterministic process where individuals detached from the real work like architects, process specialists or program/ project managers will decide upon next steps concerning any aspect of a project. There is a tiny caveat by this rule which is that some members of the club mentioned earlier might be not as detached from the real work as you wish. Clearly this must be changed if screwing-up is what you have in mind! 

3)  Follow always common sense and make rational thinking based on factual data the worst enemy of yours. 

4)   Put off  issues to later stages and resolve immediately only the most obvious ones. After all business may change her mind later on so don't bother. 

5) it's said "don't shoot the messenger" as you may have guessed already do the opposite

6) Think big and opt for massive development and gigantic releases from the very beginning. Wait until you get (check out point 1) all people necessary to carry out your vision. Choose programs instead small projects and get all your colleagues engaged by sending out regular news on your big endeavour. Communists argued that quantity becomes quality. This thought among other ones made them fail miserably and so you will my brother. 

My new article is out!

After two years of being silent I finally managed to finish and publish my article on teams who stop improving at some point and perpetuate it unless they change their well entrenched mental model. From this point I'd love to thank all people from AgileConnection who made this publishing possible. The article you may find here

Scaled Agile Framework is not Agile (with a speck of irony)

Does the old and good "Working software over comprehensive documentation" still ring a bell? Do you recall the very first time when you and your team mates were showing proudly an end-to-end working piece of a software product on the scrum demo? Do you remember how good it felt back then just opposed to skimming through a dreary project status update email? If so then stay tuned because scaled agile framework does not share the same view and they are on their way to take over a sizable piece of the market.
One of the greatest french philosophers Jacques Derrida argued that every thinking domain posses a kernel, a central meaning around which all other concepts are built. Try to move the kernel and you will shake the intrinsic structure of the domain bringing about its own destruction eventually. In the aftermath of those actions a brand new domain will appear containing the same set of concepts but with different relative meaning.
SAFe's kernel contains many concepts and one of them is "system". Even though SAFe touts "product" as playing pivotal role in their framework it is "system" which when removed tears SAFe apart. Therefore it's a system-level software incrementation and thus not product incrementation what's being delivered by the agile team in SAFe. But systems in the modern enterprise tend to be large and complex, concludes SAFe profoundly. As a result hundreds of people may work on a one single system simultaneously. Here we get a serious scaling issue though which SAFe resolves by means of handing over all integration related concerns to the higher layer. System integration team and component integration team come than handy ensuring that all parts of system-level incrementation work together. Consequently there is a need for infamous hardening sprints, but of course that's an option only. On the demo day there are two sort demos: team's demo handled per agile team and system demo where stakeholders and product people are present with (as in every decent meeting of high-class representatives) developers being absent.
Agile manifesto doesn't mention product in its core values at all. Instead it says something about interactions, working software and adaptability to changes. However just a short look on works of people who shaped agile movement in its infancy sheds a new light on the matter. Scrum for example, origins from the article "The new new product development game" by Hirotaka Takeuchi and Ikujiro Nonaka. The sprint goal in Scrum is to deliver product incrementation as written in "Agile Software Development in Scrum" by Ken Schwaber and Mike Beedle. Last but not least there is product backlog and not system or software-piece backlog in scrum. Just a short read of Mike Cohn's "User Stories Applied" learns that an user story must specify a tangible goal related to the product and thus not system needs. Additionally SAFe claims to be inspired by Lean so I've spent hours to find system orientation in Mary and Tom Poppendieck's books and guess what I've seen product everywhere and system in technical context only.
So what's wrong with swapping product with system? Both Agile and Lean stress for an active collaboration between product people and teams in order to make sure that what's in the brains of the former ones find place in the brains of the latter ones. Otherwise the risk of wrong technical assumptions (the technical architecture foundations does not reflect product evolving strategy), delivering mistaken requirements or wrongly planned product releases raises significantly high and can't be neglected. And that's precisely what SAFe tries to reintroduce in our landscape. Detachment and alienation of development teams from what the product is about. That's why teams make increments of system. That's why all those system parts are integrated together outside team context and results are discussed on the product managers and key stakeholders meeting. Does this sound familiar? I bet so.
In the best case scenario SAFe might be a staged delivery framework as suggested by Johanna Rothman. However, one may argue that SAFe is really a hidden waterfall system with long waterfall iteration on the system level and teams residing one level beneath and caring out technical details (just as Prince2 teams do and who says Prince2 is agile?).
The sheer scale of large systems is not an obstacle for agile software development. There are great pure agile ways of doing that as described by Bas Vodde and Craig Larman or Johanna Rothman to name just two of them. SAFe is not how Google deals with the topic of how to organise work between development and product. Just read "How Google tests software" and you can't help the feeling that they have done it differently.

That being said I don't claim that everyone should use agile. No, I'm very far from stating that. SAFe may fit perfectly for some organisations and that's great news. It's just this deep belief that different things should be named as different and this feeling of being proud on the demo seeing working piece of a product what inspired me to write this post.

What makes a team coach a truly happy man?

After a two months pause I joined one of my teams in their planning meeting. What I saw there made me a deeply self-fulfilled person and here I'd like to share my feelings with you. But don't be scared. I'm not going to depict what I felt precisely (I felt good, period) but instead you will hear how it looks, smells and feels like to see a professional agile team working.

One of the first things I analyze when I begin working with a new team is how the team deals with a relation between those who knows what should be build (mainly the business) and others who know how to build that (in most cases developers). In this case I went to leaders of the involved business department and told them about testing within an iteration and writing unambiguous tests for user stories. Last but not least I asked them to let their subordinates spend more time with developers so that common sense of the business will synchronize with that of developers. Once they heard my pitch their faces resembled ones of middle age scholars hearing that the world is not flat but actually forms a ball. During following 4 months we managed to flip over all entrenched ideas on how to "efficiently" manage software production and form a team which can deliver a tangible increment of working software every sprint. After that period I left them for the next two months. Joining them once again I was astonished to see the following:

• business tests every user story in the middle of an iteration so that the demo is presentation of an accepted increment that suits company's needs
• all user stories are quickly yet efficiently discussed with developer representatives and feedback is processed before a user story goes to the planning meeting  
• if there are points which are hard to guess by business beforehand then the scope of how far developers may play a trail and error game with business during a sprint is clearly confined and thus some variability is allowed in a managed way
• the ratio between committed story points and delivered ones is high meaning that there is a strong correlation between what developers claim they can do and what comes out of a sprint (improved predictability)
• everyone feels responsible for quality and always seeks ways to improve it
• business and developers sit regularly together to discuss advantages and disadvantages of their work-process. They conduct and evaluate experiments to smooth it out even more (continuos improvement where both parities are entitled to say what they think)  
• there is no finger pointing   

We all have made this happen and that's a really great achievement! From that point I'd like to thank all of them for their passion, energy and patience that made this happen. They should be proud of themselves! And I wish to all of you to have a pleasure watching such a jewel in your career as often as possible!  

A few examples of where beside IT nondeterminism works

There is a continuously growing interest in nondeterministic methods since traditional logic has proved to have failed utterly in several domains. Just before listing a few examples for you let me just define what does traditional and complex systems logic mean to me.

Traditional logic - that's mainly a true/ false logic which dates its beginnings to antic Greeks and blossomed during the second half of middle age (producing a few dozens of so called syllogisms). A modern form of this logic is called Boolean algebra - I guess a well known subject to anyone who has once studied a little bit of math, logic, statistics or computer programming. Putting aside math related details important here is that starting from Renaissance this logic has been used by empiricists as a set of building blocks that when used in the model may help making the world around us predictable. In other words a scholar could suggest a hypothesis in the form of "providing that a exists b will follow" or "if you want to establish c use a formula d". Then such a hypothesis has to be proved or rejected in the series of experiments. This simple yet ingenious framework has given us Newton's laws, antibiotics, radio, TV and many more useful ideas and products that make our living better.

Complex system logic - there is no one single logic that embraces all phenomenas described here as nondeterministic systems. Instead there are many of them like chaos theory, fuzzy logic, systemic thinking or stochastic processes to name just a few. A common feature of all of them is that they don't represent true/false logic, in most cases have a continuous (therefore not discrete) result function and may produce different results in time.
Arguably the most known complex system logic among IT folks  is feedback loop logic. The foundation of this logic is build on 3 building blocks: a stabilising loop, a runaway loop and a delay. The famous example of feedback loops is when you hire cheap but not experienced developers to deliver a project. At first you get results quickly (runaway loop), but soon sloppy design and spaghetti code begins to impede progress (stabilising loop with a delay) and thus the immediate effect differs from what you get later on.

Now it's the right time for a few examples:

1. Neuroscience - it's proved that there are two neuron layers which are responsible for vision, namely: a neuron per pixel in the eye layer and lines recognition layer. This discovery earned Nobel prize and soon scientists realised that if there were more such deterministic layers to find then we would have to have an order of magnitude more neurons in our brains than we actually posses. You need to think in terms of complex system to understand what's going on further. 
2. Spread of disease - it seems to be a very hard task to forecast how a disease will spread. But if you use a few simple rules and feed a looping system based on those rules with proper input you get a decent prediction. Results vary completely based on input and there is no continuous pattern between the results in function of input values
3. Modern steering systems - fuzzy logic, neuron networks and other nondeterministic modelling systems are backbone of all modern steering systems (beside those processing simple tasks)
4. Quantum physics - "God does not play dices!" argued Einstein but with all respect to his breakthrough discoveries he was wrong and you need to use stohastic logic (characteristic to complex systems) to predict behaviour in nano-scale world

For all of you who want to learn more on complex systems and see further examples of their usage in modern science I would recommed this lecture by prof. Robert Sapolsky

What is all about?

First of all a very warm welcome on my blog on the ways to develop software products based on nondeterministic methods!
In order to define what nondeterministic method means let's have a look at what is a deterministic process.
Imagine you're working in a factory which produces bikes. The production line comprises of  several steps in which bike parts (frame, wheels, saddle etc.) are added to make a final product. There    is a strict order that must be followed while producing a bike. For example you get first a frame and then you add a front wheel to it and then you add a hand break and so forth. There is an assigned value (for the sake of argument let's call it delivery time) to each step which says how much time it takes to finalise the step. As a result it takes sum of all delivery times to produce one bike. Planning is easy. If you produce 200 bikes per day then once you get an order for 1000 bikes you can easily calculate that it will take you 5 consecutive days to fulfil the order. That's an ideal deterministic system.
The situation gets less easy when with every order there are some details which vary like a sticker, a colour or shape of a saddle. Such variability spoils the system of production because every time you get an order you need to adapt the production process and can't simply follow the same steps. Additionally there are some other factors which you have to add to the planning equation like workers mood, probability of machine getting broken down or changing specs from your customers.
Of course such a system can still be managed by deterministic means just if you replace fixed values with average or median. Sounds good, doesn't it? But the predictability within such a system diminishes as a function of variance leaving you with a vague message to your customer like for example that the ordered items might be delivered anytime between 5 to 15 months. Arguably no one is going to fancy such news. And that's not the end of misery yet. Next to the quantitative differences (embraced by statistics) between the latter and former system there is a great chance of introduction of a qualitative change. Why is that? In the course of product creation you will make some decisions about how to deal with new requirements. Those decisions may have impact on further steps only once or twice - with an immediate result being completely different then a long term one. As a result you may face a significant flaw of your past decision later on in the process and your initial plan gets torn apart completely.
Well if above sounds familiar you face a complex system which can't be properly managed in a deterministic manner.

I believe that software production in most cases resembles complex system and therefore one should seek help in nondeterministic management methods then those which suit perfectly to deterministic environment.

There will be a lot on results and my experiences with agile software development in this blog. However, I will use agile only as an example of dealing with nondeterminism along with other topics (which will almost never collide with what agile says).

Enjoy!!