 |
| We had a Lean Coffee session before the talks |
I think that was a good pick given agile is getting a little worn out as a topic itself. Agile practices are widely in use. Perhaps the main challenge is in getting from "doing agile" to "being agile". This means organization level acknowledgment of the ideas and means entire mindset has to change.
Bob Marshall - After Agile
The day started with a keynote by Bob Marshall. He has introduced the concept of rightshifting to the community. The core idea is that a large amount of organizations are underperforming. There are some exceptions to the rule of course. That said, there's a lot we can do to improve the situation.
Prisoners of Existing Ideas
The problem is that we're always more or less prisoners of our mindset and existing ways. Replacing each person of an organization while keeping the underlying ideas the same wouldn't mean a thing. Instead of replacing people, we'll need to operate on a more fundamental level. In order to improve the effectiveness and efficiency of our organizations, we'll need to be able to imagine better ones.
What Does an Ideal Organization Look Like?
I think the greatest challenge is in figuring out what these better organizations might look like. We have certain models that we've inherited from the industrial era. Even though they sort of work, the problem is that knowledge work has unique qualities of its own. Beyond this, each organization operates within contexts of its own. All involved parties have needs of their own. The challenge lies in responding to these needs in an adequate manner.
Going Beyond Agile
As Bob put it, agile thinking gets us only up to a certain point. In order to improve our organizations, we'll need to look at the whole. Simply optimizing software development is suboptimal. Real improvements can be achieved only by taking a holistic view. As a solution Bob suggests organizational psychotherapy. That can be seen as a way to understand organization health and changing the mindset of the organization to one that's more conducive for high performance.
Forming Better Organizations
It is interesting to ask similar questions about forming organizations. Instead of conducting therapy, you actually might have a chance to build a performing culture to begin with. This might be an area that's easy to neglect when growing a company. If we understood how to perform better from the start, that would allow us to build better companies faster. Bob's ideas have merit beyond existing organizations.
Jaakko Kuosmanen - Is Agile everything or is it the only thing?
Jaakko's presentation provided us multiple different views on agile. I've tried to summarize some of the main points below:
- Agility can yield business value. Liquid assets (renting vs. owning) can yield competitive advantage when the market is volatile. The problem is that fixed assets can become expensive if the situation changes in a way you cannot predict accurately.
- When you are dealing with a fickle market (i.e., game development), it can be worth your while to experiment a lot and fail fast with ideas. Focus only on those that work. Kill your darlings.
- Projects tend to happen in process context and there's interaction between them. Depending on the view, you might have different focus. You can for instance think projects as assembly line work and discard aspects such as maintainability. Focusing on process might yield entirely different results.
- Software is just one part of the equation. It is concrete services that yield actual value.
- Especially in big organizations different business units might have conflicting views of the world. Sticking to too rigid plans without synchronization can lead to disasters.
- There's a rift between the physical and virtual world. Physical material costs whereas bits are free. This leads to different economics.
- Services and infrastructure have needs of their own. Services can be seen as something flexible whereas infrastructure is something rigid.
- It is important to understand your core competencies. Consider outsourcing parts that aren't.
- Solving the right problem is more important than solving the problem right.
- There can be a conflict between the roles of a customer and a user. Customer pays and drives development while the user might have to endure. In self-service these can be the same, however.
- Understanding what to document can be valuable in the future. A small amount of work beforehand can help to avoid a huge amount of work later on.
Markus Päivinen: How to make learning a lifestyle
Markus described how they have managed to make learning a lifestyle at Ericsson. They've acknowledged that in order to remain in business, they'll need to retain their edge.
As a result they've put a significant effort in nurturing a company culture that enables people to learn. The problem is that if you aren't learning, you are regressing compared to the competition.
They've implemented various ways in which they push towards a learning culture. I've listed the ways covered below:
- Ericsson Academy - Online courses for onboarding and learning those skills you are going to need for your job.
- Code School for kids - By teaching children you can actually learn new ways to approach problems. They have a different view on the world. That's something adults tend to lose as they grow up.
- Game Jams and hackathons - Allowing people to develop in more freeform manner might uncover hidden talent.
- Breakfast Club - Sharing a breakfast can work.
- Learnathons - Ericsson cross-trains people inside the company. They look up topics people are interested in picking up, figure out who understand enough to train, and then do it. This can be scaled globally.
The most important learning here is that you can change company culture through actions. It is the people that create the culture. Encouraging people to learn leads to improvements as the newly gained skills and knowledge is put into action. Even though learning takes time away from work, is there an alternative really?
Andy Edmunds: Disciplined Agile Delivery for Critical System Development
Andy's lightning talk showed how to take some of the ideas from agile into an academic context. The problem is that formal methods and high integrity systems are rigid by definition.
Bringing agile processes into the equation may make the techniques palatable to more people.
Juha Vuolle: Modern Companies
Juha's talk highlighted some of the key challenges modern companies face. I've summarized the key ideas below:
- The nature of available data has changed. It is becoming more structured.
- There's more data available than an individual, or even an organization, can manage.
- There's a relation between the amount of structure in data and organization performance. Too much structure can hurt performance especially in the context of software business.
- 52% of F500 companies from the year 2000 have vanished. It is the age of disruption.
- There are large differences between old and new business practices. Whereas older models are more reactive by nature, modern are rather proactive.
- There are major differences in the way we structure business (pyramid vs. self-organizing). Older companies split themselves by function and title. Modern companies organize by teams, advisory forces, and roles within these.
- While older companies favor centralized decision making, modern ones favor decentralization. Let those who have the best information make the decisions.
- Company DNA can be modeled within an operating system, a set of rules defining its limits and its approach.
- Pushing decision making to the people but it can be challenging. It is better to make a bad decision fast than a good decision late. There should be means to track the quality of decisions so better ones can be made in the future.
- A modern company should have a conflict resolution process. If something goes wrong, there should be clear ways to deal with it.
- A modern company is limited by the development of its leaders. It can be challenging to match compensation with contribution.
- There's no single recipe for how to build a modern company. Principles transfer, practices do not.
- When scaling a company up, rephrase the problems encountered.
Timo Stordell: DevOps. Boosting the agile way of working
DevOps is one of those terms that crops up every once in a while. As I was curious, I went to see Timo's presentation. DevOps isn't anything revolutionary.
Instead, it should be seen an incremental way to improve our development practices.
Small Bangs over a Big Bang
Instead of performing big bang releases, it is more beneficial to releasing smaller bits faster. Besides decreasing the possibility of disaster, this allows you to receive feedback sooner. This can also work as a competitive advantage and allow you to capture market.
Requirements Management Meet Acceptance Testing
In ideal situation your requirements management and acceptance testing should be closely connected. Acceptance testing gives you degree of security and allows you to catch potential issues before deployment. Of course there's more to testing than that but the basic idea is solid. Timo demonstrated how they perform acceptance testing using physical devices and automation. Building a rig of your own can be absolutely worth it.
Standardize Development Environments
The DevOps practice of standardized development environments is beneficial as it makes it easy to reproduce potential problems. Thanks to virtualization we can get new people aboard with little effort.
Monitor to Understand What to Develop
Monitoring can give us a good idea of how well a product is performing. I expect this could be tied to business indicators. Having data available allows you to make better decisions faster and focus your effort on the right things.
A book known as The Phoenix Project should be a good starting point for digging deeper in the topic.
Allan Kelly: Beyond Projects
The second keynote of the conference was held by Allan Kelly. His main thesis is that projects don't make sense anymore. I couldn't agree with him more. Interestingly he started out by making a book analogy.
He wrote his first books in a traditional manner. His newest one took an agile approach and completely changed the way he thinks about writing. Incidentally I've used a similar approach with mine as I couldn't get a publishing deal.
Digital Environment is Ideal for Agile
The reason why agile approaches work with book writing has to do with the fact that writing has become digital. This enables fast iteration and easy distribution. Instead of having to plan everything carefully, we can learn as we go and make decisions based on that. I would say writing a book this way is almost instinctive. You listen to the people and do the right thing.
Projects - on Schedule, on Budget, with Sufficient Quality
Projects go against all of this. Generally project success is determined by staying on schedule, on budget, and with quality. This doesn't tell anything of the value delivered. Projects don't put value in flexibility. The basic problem is that requirements change. This goes against the fixed nature of projects.
Projects Emphasize the Wrong Things
The key problem is that projects put focus on wrong things. Especially in product development we should put focus on benefit delivered. The most important question during development should be when can I deliver value next? Putting emphasis on iteration speed and value delivery instead of sticking to a plan makes sense.
While projects are temporary, software is forever. There's a clear conflict here. As projects put emphasis on getting things done by a certain date, this may lead to cutting corners and reduced quality. This sacrifices the long term view. This is not to say deadlines aren't a good thing. Checkpoints can bring focus to development. Then it becomes a problem of figuring out how to provide most value by the deadline. Focus on flow and value.
Projects put emphasis on the idea of temporary organizations. Essentially you form a task force, finish the project, and move on. The great tragedy is that you will have to break a functioning team and start all over again. Putting emphasis on teams instead would be more beneficial. Treat a team a unit and push work through it.
Software Development Doesn't Have Economies of Scale
Project model has been optimized for big. Unfortunately software development doesn't have economies of scale. It is, in fact, a converse situation! It is cheaper to produce software in smaller quantities as you decrease the amount of possible risk. It is cheaper to make small mistakes than big ones. Smaller batches work better for software as you can deliver sooner and de-risk your work as you go.
We're Still Stuck with Project Nomenclature
The biggest problem of them all is the fact that we're still stuck with project related nomenclature. This all ties back to Bob's presentation and mindset. It is difficult to see the world in any other way if you are stuck in a project way of thinking. After all that's how majority of the industry operates. A new language is needed to break down old habits. We'll need to put emphasis on producing value. As Allan put it, it's time for Waterfall 2.0 - continuous flow.
Conclusion
 |
| I ended the day with a Pepsi |
Overall the conference was quite nice. Especially the keynotes alone made the trip worth it. I probably didn't get that much from all the talks but then I've been to a quite a few conferences already and it's inevitable some of the ideas begin to repeat at some point.
If it was up to me, I would probably double the amount of normal presentations while cutting their time in half to twenty minutes. It's enough to get a couple of ideas across while forcing to keep it simple. This would give the audience exposure to more. That's the point, after all.
An interesting alternative would be to have the same amount of talks while keeping it all in a single track. As the talks would be so short, having a couple you don't care about that much wouldn't hurt. As a bonus benefit you would see talks you would skip otherwise.
I preferred the after-party location of the previous year. That might have something to do with the fact that nerds tend to like cellars for some strange reason.