CommunicationThe 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
CollaborationAnother 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".
CooperationWhilst 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.
ControlFor 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.
CommitmentWork 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.
AdaptionAgile 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.
SummaryPeople 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