As this post is quite long, you can get it in PDF here.
Some time ago, at the company where I am currently working, I suggested that we could create some posters about Lean and Agile so that people would keep it in the back of their heads on their day to day work. I also made myself available to explain, to the IT department, what Lean and Agile are all about, but because of lack of time, that explanation ended up never happening.
Lately, I’ve found that there are some people around me that have the desire and need to know a bit more about Lean and Agile, about what they stand for, how their practices should impact our day to day work, and what’s there to gain from it. So I decided to write this post in an attempt to cover that.
I’ve talked about Lean and Agile before, in a post titled What is Lean and Agile about Software Architecture but it had a very restricted spectrum. In this post, however, I want to take it a bit further.
Continue reading “Lean and Agile in Software Development”
There are many ways of partitioning an application. Usually, what we do is actually classify the code according to some criteria and organise the code following that criteria.
This chapter of the book explores four criteria:
- Functionality vs. Domain;
- Conway’s Law;
- Geographic constraints;
- Cultural concerns.
All in all, the idea is that we partition our codebase with long-term local autonomy in mind, according to history, standards and conventions, experience and common sense (Coplien 2010, p.91).
Continue reading “Architecture 1st design step: Partitioning”
Good Software Architecture embodies several Lean and Agile principles, always with the same goal of long-term productivity and lightweight feature development.
Delaying structural decisions will outcome in undisciplined structure, which in turn outcomes in waste. Therefore we must think of Software Architecture as an investment that we need to make now to get medium and long term gain.
Continue reading “What is Lean and Agile about Software Architecture”
The problem is what drives our work, it’s what tells us what needs to be able to be solved by what we are building. It closely relates to use case goals and requirements, but also to the more coarse-grained OKR’s. Continue reading “Problem definition”
In my previous posts, I briefly described the stakeholders. However, they are not Lean nor Agile themselves. What is really important, for Lean and Agile, is how they work together: Everybody, all together, from early on. Continue reading “Stakeholder engagement: Trimming wasted time”
The process of stakeholder engagement is about how people roles connect to the value stream, with everyone focusing in the product final result. As opposed to their isolated place in a production pipeline. Continue reading “Stakeholder engagement: the process”
Today I finish the writing about the stakeholders:
- The business
- The customers
- The domain experts
Continue reading “Stakeholder engagement: The business, customers and domain experts”
There are five major stakeholder areas :
- Domain experts
Both Agile and Lean tell us to break the traditional approach of contacting the stakeholders at a specific moment of the project development, and instead keep a permanent contact with them throughout the project development.
Continue reading “Stakeholder engagement: The end-users”
This chapter of the book talks about the people involved in the system development and the processes that guide their work:
- The value stream
- The key stakeholders
- The process of stakeholders engagement
- The network of stakeholders
As there is a lot to cover in this chapter, I will make several posts to cover it in small batches.
In this post, I will write about the value stream.
Continue reading “Stakeholder engagement: The value stream”
Chapter two of the book is a small preview of the whole book, where the authors talk a bit about:
- engaging the stakeholders
- defining the problem
- what the system is
- what the system does
- the code
Continue reading “Agile Production in a Nutshell”