Get certified - Transform your world of work today


Are You Really Working in Agile Mode?

Reach for a level above with "super learning"

8 March 2016

Does your organization have a project that has been rolling along for years? Are people working on the same Agile team and delivery sprint after sprint? Does your product owner challenge the Agile team with a never-ending list of changing requirements? If this sounds familiar, you are no longer working in Agile mode.

From a program management perspective, have you skipped the Daily Scrum, lost focus on the retrospective, redefined stories, and adjusted the velocity every three months? If this sounds familiar, you are no longer working in Agile mode.

Does your burn-down chart have revisions? Do drafts become more detailed than necessary and trace back to user stories, only to reappear in your sprint? You are no longer working in Agile mode.

Do you have high turnover, or do roles change often? Do you have newbies who love to learn and practice Scrum and do it better and faster? Do you see a sudden increase in velocity by certain priority functions? You are no longer working in Agile mode.

Does your product owner give you changing or redefined requirements, or does your product owner work his or her own way? Are roles being redefined? Do members on the Agile team have the same job sprint after sprint? Has velocity decreased or is velocity ever measured after the first few sprints? You are no longer working in Agile mode.

When the Definition of Done is redefined, business analysis becomes the focal point, architects approve the same code, and the security and compliance team are pulled to redo the sprint to complete new requirements, thus returning to a sprint zero, you are no longer working in Agile mode.

A project that is run by the same team; includes the same functions as in an earlier release; and has a new set of requirements to deliver a simpler, better, and faster product, then achieves a single Definition of Done (without a sprint zero) is an Agile, Scrum-run project. If the same project is going too well for consecutive years, then super retrospectives are needed on the project or program management, not on the Agile project.

A super program/project retrospective brings out the efficiency and productivity of the team. The case becomes very clear: How much did I save at the end of the day? How productive was my team? How efficient was the same delivery when it was run in another project? How can automation speed the delivery of a new product? Executing in Agile increases the lessons learned and expands the list of best practices. Your project and your team are the perfect match for Agile only when you introspect in a defined time period. This perfect match is exemplary of mature, practical program management and cannot be practiced with an inexperienced team running Agile for less than a year.

Agile runs more efficiently when you handle a non-IT project with IT as a project delivered as a function or a service. The benefits of Agile are sustainable and ultimately make the stakeholders happy. I'm sure that most senior leaders who have started Agile in their teams are waiting to experience the moment when strategy and planning reach the level of the program's D-Day.

I would be glad to read your thoughts and comments.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.5 (2 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up