Communication
The keystone of all good agile implementations is good communication.The last post listed meetings & visual work tracking which are are all ways to communicate but what is key is that an agile team doesn't restrict themselves to just these methods, they will communicate whenever they need and not restrict themselves to "set" meetings.
For me agile revolves around communication - communication between members of the team, the team and the larger business, the business and the customer, etc. From communicatin we get
Collaboration
Another key part of a good agile implementation is collaboration, it forms the basis for working in the team and for the team working with the customer/business.I mentioned capturing user stories as requirements in the last post, these should involve collaboration between the customer/product owner/product champion and the team. The team shouldn't be separate from these discussions it should be a part of them able to provide not only technical insight but frequently a different view on the product as the team has unique domain knowledge from working on the "product".
If there is no collaboration then people tend to fall into silo's & lose the view of the whole product as well as fostering the mindset "it's not my area/problem/issue/job".
Cooperation
Whilst collaboration is about working with other people toward a single goal,cooperation is about working with others towards your own goals. Think about this. In a team everybody is doing their own work to pursue the larger goal that the team is working towards, but an agile team co-operate understanding that everybody needs to complete their work for the team as a whole to succeed.What does this mean in practice? An example isif one team member finishes their work and can see other people still working on theirs they offer to help them complete existing work before starting anything new.
Control
For a long time developers were told what they had to work on, when they should work on it and often how long it should take them to complete it, they had no influence over what they did or when.Agile turns this on its head, collaborating with the business the team should be involved in all aspects of the work from generating user stories, prioritising the work, developing, testing, etc.
This apparent reversal of traditional control is done to allow the team to be able to make decisions quickly, rearrange the work based on changing circumstances/priorities to enable them to deliver the work.
Commitment
Work needs to be completed & users using it for it to be of any value to the business, people working in an agile environment understand this.Don't confuse this with the team committing to complete work in a sprint from the older Scrum guides, this is the business being able to trust the team to complete the work, this doesn't mean working ridiculous hours to finish by the end of an iteration(although the team may decide to do that), it is knowing that when a piece of work is started (barring any changes in priority or direction) the work will be completed and delivered.
Adaption
Agile isn't static, when you first start you may have a framework that you work within but as a team becomes more experienced they use techniques like retrospectives to determine how they can improve what they are doing.Should you wait till a retrospective to make a change? No. Just like you shouldn't wait until a meeting to talk to other people there is no reason why you can't make changes to the process outside the retrospective.
Summary
People will often point to the agile manifesto and say "that's agile" but it doesn't tell the whole story, other people will point to the agile principles which provide more examples of how an agile team should work but still can't convery the subtleties of working in an agile environment.Underlying both the manifesto and the principles are the concepts I've outlined above, regardless of if you are practicing an agile methodology or not, you can tell if a team/organisation is agile by observing them and seeing if their culture embodies the concepts listed here.
In my next post I'm going to go into how some of the benefits of being agile, often listed as reasons to go agile, are in fact side-effects of having the right culture and mindset based on these concepts combined with the practices from my last post
When you "do Agile" can you answer the two key questions for the business: When will it be done? How much will it cost?
ReplyDeleteIn the post after this What does a good agile environment give you? I touch upon these particular subjects.
DeleteThe tl;dr version is that if you are truly agile the team has demonstrated delivery of working software and the business can predict themselves when something they have asked for will be done (and what is done anyway? dev done, test done, deployed?); the "how much does it cost?" is overshadowed by "what value is this piece of work?" the cost should be easy to calculate based on how long it takes the team to deliver a piece of work * number of people in the team plus anything else the business wants to factor in.
For a more detailed treatise on this see How to calculate the cost of an agile project, and there's Alistar Cockburns article on Agile Contracts.
There is only 1 definition of done for a business. It is working without faulting in production.
DeleteSo your solution for determining how much something costs is to do it, then add it up? Do businesses have infinite money?
That's a good definition of done although regardless of how you develop it the chance that it will have zero defects is very low, would a better definition be in production and working as expected?
DeleteI'm sorry if I wasn't clear in my response about cost, I was not suggesting that you develop it and then work out how much it would cost. In a good agile environment you should have empirical evidence of how long things have taken to develop previously and this can be used as a guide, if not predictor, of how long it will take to develop similarly sized/complex work. With this information you can make a simple calculation based on cost of your team and time taken to deliver similar work before plus whatever margin the business would like to add.
Hopefully this clarifies things.