Agile criteria checklist

Does your project board (including the project manager) understand the Agile principles and do they fully support the team in following an Agile approach in this project?

More explicitly: Is the business owner involved in the intake discussion and has he had a presentation of the business communication pack or a workshop alike?

Is your customer able to collaborate with the team on a daily basis. Will they commit to being part of every sprints planning session, closing demo and sprint retrospective ?

Does your customer understand the Product Owner role and is he willing to invest time in fulfilling it to make the project a success?

Are the team members at least 32 hours available for the project and 100% allocated to the team?

Does the team consist of minumum 5 people and maximum 9 or can it be split up in multiple teams of that size?

Do the team members have a dedicated room to work together with the facilities needed? When in mulitple locations, is there enough virtual team support (electronic whiteboards, roundtable cams, chat always on etc) to enable the team to have standups and planning sessions together over multiple locations? Is the project investing in travelling people in beginning, getting these tools in place, and use experienced coaching to get this team going?

Is the scope of the project allowed to be changed?

Is the project board willing to invest time and effort in being trained and coached to work in an agile way?

Are you accepting to use Scrum as a best practice rather 'by the book' the first 6-8 weeks?

Do you have someone that will take the Scrummaster role?

Intent behind it
The Scrum methodology asks for a project environment to let the team do their thing. If projectboards steers 'old-skool', the team is not able to take ownership and be transparent and self organize to maximize value Looking at all the research and experience, involved business is one of the key success factors. The Product Owner has to be someone from the business that will take the role of explaining WHY, prioritizing, giving context, accepting sprints of work, working with the team. Intent is to maximize interaction between business and IT, ensuring that they learn to understand each other, and create full transparency of the delivery system. It also enables the business to really respond to business events. Question of business is often: "This will take so much time, can i delegate it to IT?" That can be done technically, almost always leads to unneeded software, expectations going astraigh, and so on.. Intent here is to ensure that people from business get proper training and coaching in the role of Product Owner, so that they can fulfill the role effectively All research and experience show that the concept of a multidisciplinary team working on real business value is the most effective way to organize. It also shows that stability of teams and the people inside make a huge difference; teams represent value. Keeping people in a team as dedicated as possible, giving them equal rights and ground in the team, and create focus (less task switching) ensure massive productivity boosts; over 40%. To get this 'hot-spot behaviour', teams need to be dedicated for the most part; 80% of the team should be dedicated, people should have 32+ hours on the project, and locations should have balanced number of teammembers. The Agile community has a strong rule for 7 plus or minus 2. The idea is that Communication Saturation kicks in in mostteams at 9 (research on ad hoc communication, etc). When distributing teams, I would urge even stronger to not stretch this yet.

Importance (0-10)

Intake 1-5

10

The intent is that we want this team to work as a team. For that the team needs to feel like they are less than 30 meters apart (the threshold for enabling adhoc communication, where a lot of team dynamics happen, stops roughly at 30 meters apart). So this is to resolve: are you aware of the challenges, and are you willing to invest in that? Agile is aimed at shortening time to market, and creating more effectiveness in the project. The main thing for effectiveness is the depth of scope. There is 50-60% of features in software that is never or rarely used. By enabling flexibility in scope, and combining it with shortcycled delivery system, this waste can be left out. The question therefore is "Are you allowing scope to change, because then we can save you a lot of money" Too many Agile implementations fail because of the just 'doing some Agile like thingees'. Taking it serious and use best practices and experience pays off big time" This will ensure the team and project will first get experience before they start fiddling with the controls that Scrum gives you. Too many times teams do "Agile In Name Only". They do standup meetings only once a week because they think it is better, they do not use the timeboxing mechanism, they skip the retrospective, etc etc. Once you have some experience, you can value the different processes and rituals in Scrum, and THEN you may vary them to improve. This ensures: Dailystandups, Planning session, Demo, Retrospective, Scrumboard, Planning Poker, Scrummaster, Productowner, Product Backlog, Storypoints, User stories The intent is to create a self supporting team as fast as possible. The Agile team coach can take this role at the beginning, and he needs to coach the designated Scrummaster rightaway. Too many times coached get sucked into the operational handling of the project, a model that does not scale and is not effective. A senior team member should take the role of scrummaster, and the role should become parttime within a few sprints.

10

85

Weighted Value

Agile Ready?

Not at all

Not at all

Not at all

Not at all

Not at all

Not at all

Not at all

Not at all

Not at all

Not at all

Not at all

MARK 1: Not the slightest chance agile will succeed. Fix your impediments first!

0 162 247 332 417

MARK 1: Not the slightest chance agile will succeed. Fix your impediments first! MARK 2: Risky - we are willing to give it a shot, we'll use a slower more lean appro MARK 3: Suitable - there are some things to take care of in first sprints - PO does n MARK 4: Good - most important things are accounted for MARK 5: This is perfect for agile - all good to go

x your impediments first! se a slower more lean approach for turning into agile. (for example start with a Kan Ban board of their waterfall process) needs an excelle of in first sprints - PO does not fully understand etc

process) needs an excellent coach

0 1 2 3 4 5

Not at all Barely Scarsely Just enough Good Fully met