Have you heard of these? More likely about the first one than the second.
Here are the definitions:
Parkinson’s Law: „Work expands so as to fill the time available for its completion.”
Hofstadter’s Law: „It always takes longer than you expect, even when you take into account Hofstadter’s Law.”
These two seem to contradict at first, seem to complement each other at the second look, and turn out to say exactly the same thing finally.
1st look:
According to Parkinson’s Law, it seems that work would always take less time than estimated under ideal circumstances, while according to Hofstadter’s Law, work seemingly always takes more time than originally estimated, no matter how big the estimation is. Contradiction.
2nd look:
Parkinson’s Law talks about large bureaucratic organizations, where people’s work is meaningless and thus they get lazy and procrastinating. Hofstadter’s Law is about aggressive and ambitious organizations where everyone is pressed to deliver results fast. Complementing.
3rd look:
According to Parkinson’s Law, preliminary estimations are screwed, as people will cheat them, and even if everything goes well, probably they won’t finish work ahead of time. According to Hofstadter’s Law, preliminary estimations are screwed, as no matter how conservatively you estimate, you’ll keep thinking for a very long time that you are always there, and then in the final moment, everything breaks down and you’ll have lots more left to do. Same thing.
Tag Archives: estimations
Agile: How different and still how similar…
Recently I’ve met several people from a small software company. As lots of startups in my country, they used to start their business in the professional service area, but building on more and more similar successful projects, they have started to productize their software.
They are just in the beginning of adopting an Agile process, and talking to them revealed to me (in spite of being in a quite different area of the software industry and having a company 2000 times smaller than the one I work for) how similar challenges do these people have compared to what I’ve seen in the last 10 years:
- Struggling with upfront estimations often proving to be wildly wrong
- Learning that hundreds of pages of specifications are worth much less than frequent feedback from customers
- Priorities of features changing frequently, both needing to serve a long-term product roadmap and short notice requests
- Stakeholders having vastly incorrect assumptions about complexity of software engineering work
- Finding the right balance between perceived speed and real speed, like spending overhead effort on removing technical debt and doing test automation for continuous delivery (utilization vs lead time)
Surprise, surprise…
A challenge for scientists on Agile tradeoffs
The other day I attended a meeting where the main topic was Agile process standardization. During the last 9 years of working with Scrum in particular and Agile in general, I’ve been constantly struggling to understand why certain people think such thing as a fully standardized Agile process has right to exist. Of course on the meeting in the end we agreed that this kind of thing should somehow happen, but that was pure diplomacy on my end (why hurt people’s feelings if they are so obsessed).
See Henrik Kniberg’s illustration for example: http://blog.crisp.se/wp-content/uploads/2014/09/Screen-Shot-2014-09-15-at-13.58.35.png
So here’s my question (or you may call it a research challenge for software engineering methodology scientists if you wish): Is there a way to figure out where to draw the slider regarding these dimensions? In a certain situation, should we do detailed estimations or not? Does sprint planning make sense or we should just kanban our tasks? Should we have more of written specifications or we should have more meetings to clarify what needs to be done? Should we scream to management telling that wanting a detailed plan for the next half year and at the same time always interrupt the team is plain schizophrenia, or just let things flow and let our survival instincts solve the problem? Should we let developers just do things their way (often ending up in perfectionist procrastination) or be pushier (and then see the motivation of the kings of today’s world deteriorate in an instant)?
These daily decisions may depend on many things of course, the main ones probably being actual project situation, company culture and individual people being involved. My theory is that always individual people win, but this is just a highly subjective idea.
So all the people who believe measuring this kind of stuff, come and convince me!
Good and even better Lean / Agile books I’ve read lately
This is a short review about the books I’ve read lately in the area of Lean and Agile software engineering and project / product management methodologies. Random order, fully subjective, very brief. Rating is one to five stars.
Agile Estimating and Planning (Mike Cohn) {***}
If you believe that it is possible to create long term project estimations and plans in the context of agile software engineering (which I don’t do), this book is for you. Precise, well defined methods to handle velocity, use story points, create release plans. Nice illusions.
Scrumban: Essays on Kanban Systems for Lean Software Development (Corey Ladas) {****}
Great summary about the evolution of software related project management methodologies and how Kanban can be introduced for teams currently within the Scrum camp. Nice overview, sometimes a bit too philosophical (which I liked but probably not for mass consumption).
Beyond Agile: Tales of Continuous Improvement (Maritza van den Heuvel, Joanne Ho and Jim Benson) {***}
A good set of practical examples of using Kanban, mostly from the field of software engineering. Doesn’t go too deep but contains some nice practical ideas.
Kanban: Successful Evolutionary Change for Your Technology Business (David J. Anderson) {****}
You could expect me to say this is THE book to learn Kanban from, but I’m not sure I want to say this. The book is too much on the theoretical side and not compact enough to be appropriate for mass consumption. However, it provides an excellent overview on how the Kanban for software development method was invented (not surprise, as the book author is the inventor of the method), and also explains some concepts that I couldn’t find in other books (like classes of service for example).
Kanban and Scrum – making the most of both (Henrik Kniberg and Mattias Skarin) {*****}
This book is very cool, and the online version is even free (or it was, when I downloaded it)! A great summary of the main concepts of Scrum and Kanban, comparing these, so that everyone can easily understand what the main similarities and differences are. Explicitly for mass consumption, easy to digest and very compact.
The Lean Startup: How Today’s Enterpreneurs Use Continuous Innovation to Create Radically successful Businesses (Eric Ries) {****}
This one is probably the most popular among all of these books, however I gave it only 4 stars. The reason is, that despite the Lean Startup is a fantastic approach to do product management in a completely agile way, its use is quite much limited to due the fact that it is, well, for startups only. Of course there is blah about how universal these concepts are and blah blah about how big companies applied this, but still, even though lots of concepts introduced here are useful for everyone, and the book reflects very well on the trend that moving to the cloud makes things behave tremendously different, most of this stuff is quite hard to apply in a large enterprise context.
The Lean Mindset: Ask the Right Questions (Mary Poppendieck and Tom Poppendieck) {**}
This book was a bit of a disappointment. I expected something that is either revolutionary or summarizing things in a unique way (from the people who introduced the notion of Lean in the software engineering world), but what I got was a random collection of topics without too much added value.
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (Gene Kim, Kevin Behr and George Spafford) {*****}
This is an amazing one. Once in a presentation I gave in a developer conference lately I happened to say this was the best novel I had read in the last 5 years. Yes, this is a novel, and still, it gives you a good understanding about what DevOps is, what the concepts behind Lean are, and how much it’s all about people.
Lean Beliefs: the new name of my blog
First of all, if you are a reader of my old peter.csontos.info blog, congratulations for finding the new one!
Why did I make this change? The root cause is very simple: the web hosting service provider I’m working with has announced that they are discontinuing the service I’ve been using for my blog. Therefore, I had to change both the domain name of my blog and the content management system used. The new CMS is WordPress, which is something I seem to like using (after less than one day, but still, first impressions are important, right?).
Luckily Go Daddy provided not only a way of moving the content of my old blog to the new one, but also published an excellent step-by-step guide about how to do it easily. So here it is, old content is all here, and new stuff is coming up soon.
I still have to tweak the look and feel a bit yet, but this is already a minimal viable product, so enjoy!
By the way, I think I owe you an explanation about the name itself.
Many topics about lean and agile software engineering and project management methodologies are highly subjective and sometimes even religious. Is TDD dead or alive? Can we count on estimations? Should we invest in test automation? Can the outcome of software engineering be reliably measured? Sometimes it’s not too hard to find answers, but sometimes it seems to be close to impossible.
However, anyone can definitely have something about these tricky questions: subjective personal opinions, or in another nice word: beliefs.
Introducing Kanban to Scrum people
Yesterday we had a Kanban info session with my team and it was great.
In order to make this Kanban thing look less of a disruptive and crazy idea for our team, I asked colleagues from the German headquarters of our company to give us this short introductory training. There’s quite some enthusiasm around Kanban within SAP already, as you may see from this Lean Kanban Central Europe speech video from last November. It’s not hard to introduce the Kanban concept, as our centrally encouraged software engineering and project management process is not pure Scrum but something called Lean Development Model, so Lean idas in general sound familiar to lots of people. However, Kanban is far from being mainstream. Having this training session remotely was not an issue and using video conference helped a lot to make it even better.
Here comes the interesting part.
To my surprise the hardest things for the audience to understand were not limiting work in progress (I guess because everyone feels that too much multitasking is bad) or the lack of the sprint rythm (because we have to re-plan our sprints very frequently anyway as the world around us is so dynamic that sprints cannot be short enough).
The hardest nut to crack was the lack of concepts such as detailed upfront planning and estimations. Of course you can do this in a Kanban environment, and Kanban itself has some elements addressing this need (for example “Fixed Delivery Date” class of service), but it’s not a core concept. In our environment and company culture, it is (still) a very strong expectation to plan releases upfront and give commitments well ahead.
We should learn how much of this planning and estimation addiction is a true must (external requirements, constraints, dependencies to other teams etc.), and how much of it is simply an old bad habit of the team. How much should we keep and how much of it can we transform to something more agile?