![[:pl]Leading a successful PMO in the times of Speed-to-Market & Agility. An exclusive interview with Peter Taylor[:]](https://cdn.shortpixel.ai/client/q_glossy,ret_img/https://agilepmo.pl/wp-content/uploads/2014/10/desk-150x150.jpg)
Agile is about a fundamental shift in thinking. “Agile is not a process is a mindset” that was the title of Janusz Gorycki’s presentation at New
Trends in Project Management 2012 conference held in Sopot in May. Also Bob Hartman has a good presentation on this topic ” Doing Agile is not the same as being Agile. The essential point is that we are “Doing Agile” when we follow practices and we are “Being Agile” when we act with an Agile mindset ” set of values and beliefs defined in Agile Manifesto. According to the survey results and recommendations
presented in “Agile Maturity Report ” Benchmarks and Guidelines to improve your effectiveness” a broken waterfall based project execution approach is not sufficient reason to commit to Agile. Agile is not a “silver bullet” or a solution to a mission critical initiative without any background in the approach.
The most popular Agile framework is SCRUM, although from the discussions with practitioners I know organisations very often tailor their
approaches to their needs. Steve Denning, Forbs’ contributor, described practices that facilitate agility as:
(1) Work is organized in short cycles: (2) Management doesn’t interrupt the team during a work cycle. (3) The team reports to the customer, not the manager. (4) The team estimates how much time work will take. (5) The team decides how much work it can do in an iteration. (6) The team decides how to do the work in the iteration. (7) The team measures it’s own performance. (8) Work goals are defined before each cycle starts. (9) Work goals are defined through user stories. (10) Impediments to getting the work done are systematically removed.
approaches to their needs. Steve Denning, Forbs’ contributor, described practices that facilitate agility as:
(1) Work is organized in short cycles: (2) Management doesn’t interrupt the team during a work cycle. (3) The team reports to the customer, not the manager. (4) The team estimates how much time work will take. (5) The team decides how much work it can do in an iteration. (6) The team decides how to do the work in the iteration. (7) The team measures it’s own performance. (8) Work goals are defined before each cycle starts. (9) Work goals are defined through user stories. (10) Impediments to getting the work done are systematically removed.
Adopting Agile is about transforming the culture of a company to support the Agile mindset. I really like the conclusion from one of
the yesterday’s discussions during Agile3M meeting on Agile practices – first Tricity Agile community meeting, that Agile is about creating a culture/ team environment where everyone is self-motivated to contribute to the overall success of the project. That’s also my understanding of Agility.
the yesterday’s discussions during Agile3M meeting on Agile practices – first Tricity Agile community meeting, that Agile is about creating a culture/ team environment where everyone is self-motivated to contribute to the overall success of the project. That’s also my understanding of Agility.
Agile3M meeting update
The first Tricity Agile community meeting was held yesterday in Sopot and gathered 21 Agile practitioners, supporters and others interested in this new approach of working. The umbrella subject of the meeting was “Retrospectives” and 3 tables with more specific questions were organized: A) Tools & Techniques, B) Problems, C) Solved Problems. Each person after 20 min discussion at one table moved to another table to be able to hear and talk on all topics.
Generally, most of us take part or run reflection meetings regularly (after each sprint/ milestone) and start from positive aspects of the project/sprint by asking a question “What went well”? to move to the problems: “What could have gone better/ done differently”?.
One definition of insanity is doing the same thing over and over expecting a different result. Project retrospectives are a powerful opportunity to find and change the things that lead to undesirable results
Some tips on effective retrospectives:
- Start form positives to give credit for achievements and accomplishment
- Discussing what could have gone better also can be constructive, especially if your intent is to identify needed changes.
- Keep everyone focused on the process and potential remedies instead of character assassination and “blamestorming.”
- Implement top 3 changes – most people will willingly participate in retrospectives if they know that their efforts will not be ignored
As a result of more frequent structured learning, team members become more adept at reflecting collectively in a group format – enabling them to feel more competent and skillful in the art of addressing sensitive issues and communicating in ways that reduce the impact of defensive routines, blame, and avoidance. In some cases a kind of “ballot box” is used to encourage less confident or shy team members to feedback on the project unanimously and at the time they feel like. Although not everyone fancied the idea due to the fact I mentioned before that Agile is about creating an open minded, positive and less judgmental environment.
Project teams stop and reflect at regular intervals while the project is in flight so that they can define improvements and tangible action items that can be actively applied during the next phase. The result is learning and performance improvement as the project progresses, reducing the risk of project failure, improving team effectiveness, and providing real- time feedback and development opportunities for project members.
I would like to thank the organizers Hania, Bogdan and Jakub for the opportunity to be a part of this interesting meeting and look forward the next one ” we have agreed to meet on a monthly basis. Good luck with your retrospectives!
0 
There are 0 comments