There is a concept of being “ad-how” vs “doing agile” vs “being agile”.
[[adhoc]]
[[table of points]]
[[adhoc, team meeting, no stand ups, no documentation, milestone projetc plan, no done done]]
[[doing, daily stand ups, no demo day, maybe planning, no retrospective, no product owner]]
It is a hard distinction to understand when you start the agile journey, and for me it was only when I had coached a team that did agile and then subsequently coached a team that became agile that I could understand there was a difference.
A team that is doing agile follows all the disciplines and approaches of the agile process, but never become self managing or a team that will achieve their maximum velocity.
A team that is being agile also follows the agile disciplines and approaches, but achieves their maximum velocity and therefore become a high performance self managing team.
It is a subtle difference and is difficult to explain, but it’s important to understand the difference. So I will explain it via the use of comparisons across two teams I experienced to highlight .
==Agile Disciplines.
The doing agile team follow all or some of the agile disciplines, daily stand ups, sprint planning, backlog grooming, retrospectives, demo day.
There is another version I call adhoc agile, this is where the team have a daily standup and that is the only discipline they undertake and they call this agile. They normally bring their coffees as well so they are very obvious
But the goal of doing these disciplines is to say they have completed the discipline. They will often only undertake some of the easier disciplines, and not the harder ones such as demo day and backlog grooming.
The being team use the disciplines to understand where they are and what they need to do to deliver their promises. They engage in the disciplines with rigour as they understand that planning upfront, constant collaboration and review and lots of little improvements gives them a better chance of success.
==Agile Team
==AgileBI Process
The doing agile team will break their sprints down into iterations, where each sprint is primarily focussed on one part of the BI lifecycle. So sprint one will be focussed on requirements gathering, sprint two on modelling and data integration, sprint three on visualisation and testing.
The being agile team will ensure all these parts of the BI lifecycle is undertaken in one sprint. They will go from requirements through to visualisation using a thin slice (also called a steel thread) approach. The first sprint will be