When you put the concepts and practices together the result should be an agile environment with everybody aligned towards the same goal
TrustOne of the biggest gains that you get in a good agile implementation is the increase in trust between the organisation and the team.
Historically projects have failed and organisations have lost trust in teams to deliver so they then started implementing tighter project management in an attempt to ensure projects succeed, which frequently leads to more project failures.
The trust can be restored with the team increasing communication with the rest of the organisation by being transparent with the work (tracking work on a card board, charts showing progress, meetings, etc) and through collaborating with the rest of the organisation about work being done and the work to be done.
If the team is trusted to deliver the focus moves from when something will be completed to what is to be completed and how soon it is needed.
ValueFrequently work is prioritized based on a vague idea of what the business thinks is best for the product but often without any context of how simple or complicated a feature will be, collaborating with the team can feed in to discussions around the cost of developing that feature versus the benefit the business anticipates it will get from it.
Value itself is a tricky thing to pin down: is it about money, cost, user experience? Recently there have been some posts (notiable this post and this post) discussing value and showing that it is a very nuanced area.
The good thing about this is value will need to be considered and discussed amongst everybody involved across the business so that everybody understands value around the work being done it can help them with making decisions themselves as to priority of the work.
SpeedOne reason that organisations want to adopt agile is because they are under the impression that it will speed up development, they are then disappointed when following a methodology the work isn’t being done any faster.
The potential increase in speed, and it is only potential, comes about mainly because with better engineering practices, building the features that are of most value and focusing on creating working software the business ends up being able to use/sell the software in days/weeks rather than months/years.
The people aren't actually creating the work any faster than they were before it is just that they are having to do less rework which means the software is available to the end users sooner, and there should be less defects meaning less time needing to be spent on support all of which combines to allow more time to be spent developing the product in the first place.
FlowGood agile implementations don't restrict themselves to looking at the team creating the work, they look at the organisation as a whole and work out everything that is involved in creating a product, how the work flows through the business.
Once you start seeing the team as only part of the overall flow it may become apparent that there are both upstream and downstream activies which are causing problems for the organisation and it is these areas that need to be tackled to improve rather than just focusing on the team.
A side effect of this can be to question the need for estimates, if you have a team that is reliably deliverying work and is only 1 part of a bigger process what value does the business get from estimates from the team? This isn't to say the business isn't going to want estimates but it is understanding the value of that estimate in context to the larger organisation versus the value from the thing they want to create.
SummaryCreating an agile environment is hard, you can take a team and implement an agile methodology but that is only a small part of the story. Done right agile will involve a lot of the organisation (if not all of it), it changes the way people in the business look at the work and focuses them on what is being produced and the part everyone has to play in getting that work done.
More than that though it can prompt people to look more deeply into various aspects of running the team/organisation such as value, reward, motivation and learning to name a few.
Hopefully these posts have given you an idea of what agile actually looks like rather than the perception that it is a methodology or just a few meetings, charts and user stories.