Kim, Tobbe and Steve discuss – It’s not Who You Know It’s How you Know Who You Know.
Positives and pitfalls of Social Networking, Company perceptions and Honest Relationships.
Category Archives: Development
Deadlines – Looking Beyond
For many good reasons deadlines can be seen as bad things. For more context and clarity, I recommend Beyond Deadlines by Jabe Bloom.
So here is what can happen if we take the time to look beyond a deadline and ask about why it is important.
Imagine that we are going to have a birthday party.
And now imagine that we want to develop an application to help us organise and run the party.
We might start by asking for the full application functions to be ready 2 months prior to the party (which, being a birthday, is a date that is fixed).
We may find that the reason we need the application is to help us draw up the list of attendees first and this is why we need it 2 months prior.
However the other things that we need the application to do are not needed by that date and can be delivered a bit later.
Functions are needed at different times
A basic set might look like the above.
- Function to draw up a list of attendees – needed 2 months prior
- Function to create invitations and get them ready to mail – needed 6 weeks prior
- Function to order the ingredients and make the cake – needed 2 days prior
- Function to run the party (check in the guests) – needed on the birthday
By asking why a date is important, we have created a list of functions in order of priority – so that we can make an informed choice about delivery instead of trying to develop and deliver all of the functions at once.
We also have a great conversation about why each function is needed and what it will be used for.
People often set deadlines for good reasons, looking beyond and asking about those reasons is a great starting place.
Approaches
There are many ways to improve the way we work.
Approaches
Agile, Lean, Cynefin, Lean Startup, Kanban, XP, TDD, BDD, Srcum – these are just a few.
There are also many ways to apply these approaches to the way we work.
Ways to Approach
As a ‘pure’ method, a set of principles, a staring point, assembling a mixture of approaches appropriate to the problem we are trying to solve.
The great thing is that it gives us many combinations to try so that we can find solutions that suit the outcomes we are aiming for.
The down side is that it can be very hard to choose an approach – what has worked for one place, can be difficult to apply to another and get the same outcomes.
Development and Large Structures
I have been wondering about the similarities and differences between software development and large building projects.
Building a Pyramid
Take the example of building a pyramid. We firstly gather some blocks, then mark out the shape and then place the blocks in the correct places to build the structure. Tasks need to happen in a certain order, we cannot place the blocks before we have gathered them.
If we are developing in a green-fields environment, which features we build first does not matter very much. We can use customer value and learning opportunities to determine the first features. So it is less similar to a large building project.
If we are developing in a brown-fields environment, then we often need to consider existing systems and features that our customers are already using. These factors may constrain the order that we can develop and deploy new features. So this is more similar to a large building project.
Consider the similarity between fixing a complicated system defect and brown-fields development. The order of developing and deploying fixes is extremely important to avoid causing further issues and rework.
Fixing Complicated Defects
In the above example there are four boxes representing applications and five interfaces. Root cause analysis shows defects in three applications and three interfaces. The correct output can be restored when the six fixes are applied in the correct order.
Questions
- Should brown-fields and green-fields developments be recognised as different?
- Should brown-fields developments and production fixes be recognised as similar?
- Why is development work treated as better than production support work?