Ask An Agilist

Being Agile is a journey and you may have questions along the way. Ask An Agilist can help with some practical advice.

About this Blog


Recent Posts

Why Are You Here? Being A Part Of The Agile Community

Introducing Ask An Agilist

Why Are You Here? Being A Part Of The Agile Community

As a member of my local chapter, I am attempting to increase awareness of the communities of practice. What I would like is to tell your story, what has the CoP meant to you and how have you benefited from membership. - Alex


Great question, Alex! Thank you for increasing awareness of the communities of practice with your local chapter. As of March 15, 2015, the 40+ communities of practice have been fully integrated into the larger community and knowledge base here on With this change come even more opportunties to benefit from an online community and all of us from the former Agile CoP leadership team are excited about the change. It's also a good time to reflect on why we joined and volunteered with the CoP and how we benefited.

A long time Agilist, I first became a member of the Agile CoP to use one of the benefits of my PMI membership. I was intrigued that the PMI, well known champions of traditional project management practices, was offering a community and knowledge base for Agile practices. If you want to learn more about how and why the PMI started embracing Agile, read Derek Huether's 3-part series of blog posts: When PMI Introduced The Elephant. When I saw a call for volunteers in the Agile CoP newsletter several months later, I volunteered to edit the CoP blog. I had been writing my own blog for about a year, so I had skills and experience to contribute and, in return, I could build a network that spanned both the PMI and the Agile communities.

Being a part of that network has been the most amazing experience for the last four years. I have made friends with wonderful people around the globe, some of whom I have yet to meet in person and many I have. The more I consistently engaged with the community, more opportunities opened, such as helping two Agile thought leaders with their books. As a community leader, I was able to attend three Leadership Institute Meetings where we had a front row seat to some momentous evolution within the PMI. Of course, not everything is rainbows and unicorns. We have also had significant challenges. Through both the highs and the lows, I have learned a lot from this network and will cherish the memories.

Because of my experience with the Agile CoP, I would encourage anyone to actively engage in an online community such as As a member, you will have access to the collective knowledge from practictioners around the world. Be more than a consumer. Contribute. Like all of you, I am incredibly busy with my real-life job and personal commitments. The beauty of an online community is that it is possible to contribute on your time table. It doesn't have to be a big project. Find something that sparks your interest and you can do in the time you have. The more present and consistent you are in the community, the more you will become known and your network will grow.

If you want to learn more about how you can contribute to, check out the Contribute Content page. To find PMI volunteering opportunities, go to the Volunteer Relationship Management System.

Hope to see you around the community!

Posted on: March 16, 2015 07:32 AM | Permalink | Comments (3)

Introducing Ask An Agilist

Categories: Introducing Agile

The road to agility is a journey and you will have questions along the way. Ask An Agilist can help! This blog will answer Agile questions from the and PMI communities. From “How do I…?” to “Is this normal?” to “Are we there yet?”, your questions will be answered with practical advice. I invite all Agilists or Agilists-in-training to add their thoughts and advice in the comments so everyone benefits from the larger community. We are all professionals here, so use your best judgement on how to apply the advice and opinions in your own context.

The following is an example of a question (well, more of a rant) posted on my Sockets and Lightbulbs blog. While it is an example of how NOT to implement Agile, it will give you an idea of what Ask An Agilist is about.

How NOT To Implement Agile

The following comment was submitted on one of my blog articles. It’s quite a rant about Agile, so I thought it was worth addressing as a full post.


Agile is not always implemented in a good way or at the point in the life of an application/product where it can be useful and not disruptive. Agile is chaos when it is implemented with the following being taken away:

  • Complete requirements
  • Use Cases (solely relying on 2-3 sentence user stories and NOTHING else)
  • Documented architecture (which means it has not been thought through thoroughly)
  • Any kind of POC for brand new applications being started from the ground up
  • Solution design (documented or not it is just gone start coding with that you have)
  • Project Management: no milestones, no due dates, nothing
  • Test Plans
  • Test Cases (all adhoc testing)
  • Scoping meetings.

I work in chaos.

Agile was implemented in the following manner:

  • The people doing the work do NOT manage the work or the process. It is directed from the top down (meaning Director/VP is the scrum master).
  • Retrospectives are a joke. No one talks about the elephant in the room because management is present in the meetings. All suggestions give that would actually help fall of deaf ears. Retrospectives are a way for management to communicate the changes in the process they feel will help but the decision was made without non-management team members input. Retrospectives are a way for the ScrumMaster to ask leading questions to try and convince those who are doing the work to believe in the way he thinks it should be done.
  • The management of the defect tracking process moved from the QA Manager to the Dev Manager.
  • ScrumMaster believes that one day programmers will develop code without defects and pays no attention to the increasing number of defects. ScrumMaster only watches the burn down chart created off of story points from features and enhancements and does not take into consideration the number of outstanding defects.

What has been developed during an iteration has NEVER been something that could have been released. Over 200 sprints on one product and the code has never been releasable. The result is releases have NEVER been on time (or even close) in three years. Working on a team that could succeed but have their hands tied by a so-called Agile methodology makes for increasing turn over rates, aggravated employees and generally un-happy people. And, by the way, no revenue is being generated!

- Sari


This would be a case study in how NOT to implement Agile. The real problem is not Agile. It is being used in an attempt to justify a variety of organizational problems. Improper User Stories, lack of documentation, lack of scoping and planning and lack of test plans are not part of the Agile practice. The problem is a lack of discipline, at all levels. All the items in the second list are symptoms of serious leadership problems. Both of these will be problems no matter what product development methodology or philosophy your company uses. These are all human issues and need human solutions.

If your hands are truly tied and you cannot influence even small changes, then I recommend you follow your colleagues and find another job at a more disciplined, better led company. At the rate your company is going, it may not be in business much longer anyway. However, if there is even the smallest hope for change, you need to push back. Compliance just fuels the real problems. At the very least, show the discipline you would like to see in others.

You seem to have some ideas of how Agile should work and could work better for you and your team. If your team agrees, then get together and start making some changes – one at a time. From the symptoms you describe, I would recommend starting with the sprint planning process. If you’re not doing it – start. Make sure all your work has a definition of done, which includes addressing bugs. It’s not done if it doesn’t work. As for the retrospectives, when the ScrumMaster is done talking, add one item that is important to the team and can be completely done by the team (doesn’t require outside help). Then DO that item in the next sprint. When it’s successful, build on it in the next retrospective. Even the poorest leaders like to look good and a team succeeding at something is the best way to do that.

For more ideas on how to influence change, I recommend reading Fearless Change: Patterns For Introducing New Ideas.

Good luck!

Posted on: November 09, 2014 11:13 AM | Permalink | Comments (4)

"I would never die for my beliefs, cause I might be wrong."

- Bertrand Russell