This week marks the rebirth of my hope for humanity, and the #Agile and #Software communities!
I was at #Oredev (one of the largest software development conferences in Europe), and got inspired by all kinds of talks, and corridor conversations.
Below is a list of some important questions I got inspired to ask during #Oredev, and will be exploring on the Scrum Master Toolbox Podcast Slack channel as well as on this blog! Stay tuned!
What is capacity for software teams?
I continuously meet people – and #Oredev was no exception – that think that software development team’s capacity is measured in hours (or more generally in time). This is not only completely wrong, but is is also actively destructive for our industry! Let me explain…
Software teams are affected by dependencies, changes in scope, unexpected bugs in components they don’t own (libraries, components, other servers they use, etc.), and much more! These factors directly affect the time that they take to develop features, but does not affect their capacity.
Capacity is “the amount that something can produce” (one dictionary definition), therefore, any delay to planned work would directly affect the team’s capacity (less is produced). However, it’s rationally and logically easy to demonstrate that a team’s capacity is stable over time, unless the team changes. They are able to produce the same over and over again. The problem is that, in software, the “what” (software itself) changes size dynamically and unexpectedly.
So, how are we to define capacity for software teams then? That’s the question that #Oredev pushed me to ask (again)!
Here are a few possible options that are not “time”
- Number of user stories delivered per sprint (assuming user stories are “valuable”, and that’s a whole another discussion)
- Number of insights/lessons learned per sprint (in software it is relatively easy to accept that learning is close to “value”)
- Number of customer deliverable features delivered per sprint (this still assumes that those features are “valuable”)
But I feel we are just at the start of the discussion on this topic. I don’t know of any satisfactory definition of capacity for software teams, so I use something like stories per sprint for that, as I discussed in the #NoEstimates book. I want to find a better one though….
What’s beyond Agile?
I still see many companies trapped in the swamp of old-skool project management (I’m a project manager, so I have a good idea about what that means). Despite that problem (and it is a problem!), there’s a good point to be made that we need to think about the question “what’s beyond #Agile?”
Now, I don’t know what the answer to that question is. It is an open question after all, but I got some good insights and inspiration from a conversation with Marcus Hammarberg and Diana Larsen who helped me see some aspects I had not thought about.
One such inspiration was to take a look at FaST Agile (or just FAST), which I will investigate later.
Diana said something that stuck with me: “We used to push the ideas all the way to 11, but now that we are there, we need to redefine 11!”
This phrase inspired me to look at what’s happening in the community that would fit this “all the way to 11” mindset, and see what happens if we push those ideas further. An example of that mindset is the Ensemble Programming, or Ensemble Working, which was originally called MobProgramming.
What happens if we turn Ensemble Working all the way up to 11?
Oredev Delivered in this regard as well. I saw a talk by Frode Randers where he expressed the impact that changes in government can have on the systems they run at the Social Security Agency in Sweden. In that talk, it became clear that in some of those teams you’d need lawyers, administrators as well as IT people to be able to be #Agile and deliver on the changes that the law imposes on their software! (That talk also reminded me how our societies run on software, and that’s why our work in the #Agile community has HUGE impact, but that’s for another post!)
What is the essence of Agile?
Another question that came up for me was related to #Agile, and what is its essence. Without understanding its essence we can’t be true to it, and therefore cannot implement it in practice.
Now, some would argue that the Agile Manifesto and its principles define what the Agile essence is. I would agree in general, but as a practitioner I need to think about the multiple different applications of the manifesto, and try to assess what is essential in all of those.
In the past, I’ve used Retrospectives and short feedback cycles (hours, not weeks), as the core essence of Agile. Others have used other aspects, that I agree (and disagree) with. So, I’m still not fully satisfied that we fully understand what the essence of Agile is.
This Scrum Master Toolbox Podcast episode with Joshua Kerievsky, is a good place to start investigating what is that essence.
This question is one that I’m sure I’ll continue to explore over the years
Why are we re-hiring Project Managers in the software industry?
I remember a few years before CORONA (so, that’s not the excuse!), a large software company (in the retail space), started hiring project managers. I remember telling the Agile Coach/Scrum Master group at that company: “leave now while you still can!”
A few months later, they started leaving, and less than a year after that, the company had fired all the Scrum Masters and Agile Coaches!
Project Managers bring a promise of “predictability” (with plan and follow progress against the plan), and “certainty” (because of the illusion that “if we can plan it, we can do it!” A very expensive illusion!). Scrum Masters and Agile Coaches come with a different promise, one that most managers don’t understand, or even care about: empowered teams are more productive!
But how could managers care about that promise, if what they are being asked to do is to reduce costs? They do this with head count reduction, redundancies, lay offs, and outsourcing IT (don’t even get me started on that).
Managers don’t understand how to manage software organizations today. I’m not blaming them BTW. They can’t know! SW is so new, that we don’t even have a proper understanding of how to organize for SW development! I mean, we are still trying to use Project Management (invented at least in part to help lay down train tracks in the late 1800’s PDF Article) to manage SW which is infinitely more complex, dynamic, and (when you add business aspects) nearly chaotic!
So, given that Project Management strategies are so inadequate to SW development, why are SW companies hiring Project Managers again?
Independently of this question, we need to acknowledge that this has a direct impact on the ability of those companies to use, and benefit from Agile SW development!
I’ve seen it happening! Hiring project managers, setting up a PMO is a very clear step away from #Agile (less adaptable, more planning, more upfront designs, focus on plan completion over adapting to change, etc.)
“I don’t think software development means what you think it means!”
Overall, I would say that something that came up over and over again at #Oredev was this idea that what we think (including agilists!) software development is, is quite different from what it is in reality!
For example, we still think estimation is a valid strategy in SW development (it’s not! #NoEstimates), we think that a top-down, detail oriented planning strategy works (aka Project Management), we still think that “coding” is the bottleneck (it isn’t! Thinking is the bottleneck, and for that it’s better to work with “all the right people in the room”, aka MobProgramming/EnsembleWork).
Given that mass-market, large scale, software development is so young (maybe starting in the 1980’s at the earliest), we can safely assume we haven’t yet scratched beyond the surface of what this kind of work requires from management.
Software development is a socio-technical problem whose organizations suffer from a little known phenomenon called Conway’s Law, and some of the key tools in software development (like object oriented programming) hadn’t been made “popular” until the 1970’s! (PS: many still don’t know what OOP is all about. Check out the SOLID principles which, themselves were published in the 2000’s!)
So, no, I don’t think that SW development means what we think (today, early 2020’s) it means!
Conclusion
If nothing else #Oredev taught me one thing! We need more in-person, multi-disciplinary events, that bring “all the best people together”! So, I’m going to put together an effort to organize just that kind of event in late October 2024 in Tallinn Estonia. I’m looking for volunteers for the program committee! Are you interested? Let me know at AgileOnlineSummit@oikosofy.com! Let’s move our industry forward! Together!
