The Missing Pieces For A Winning Agile Project (Episode 1)
The experience shared below was based on the real cases of the experts in project management. Going through the stories can bring you valuable insights and if it helped, leaving comments will make us know how to improve the content!
Interviewer’s question:
Discuss your most concerned factors in every IT projects that you think it is missing or unknown to all the theories out there.
Gary Gueltig
About the Interviewee: Gary has been a project managers with more than 20 years of experience in the software solutions industry include strategic roles with Texas Instruments, Clarke American Checks, Wachovia Bank, Bank of America, IBM, LBMS, and HSBC Mortgage.(Visit Gary LinkedIn Here).
Without any hesitation, I can certainly point out these 3 things as my most concerned factors in every projects.
1. Client organization operates on a ‘fixed budget’ process which requires estimates be developed and managed following traditional timelines and stages. This hinders use of many Agile methods.
One larger banking organization’s IT organization I managed project for took significant steps to train staff on Agile techniques and reorganized team roles accordingly, but did not change its project estimating (budgeting) process.
The PMOs continued to required detailed project budgets (headcount and other resources) by quarter regardless of the way the project may ‘fall out’ over sprints.
This left project managers having to keep two sets of books.
One prepared to satisfy the PMO tracking and another set to reflect the way sprints would utilize resources.
Best practice Agile recommends that budgeting be performed at a more macro level, preferably where a budget is established and the team produce as much as they can within that duration and cost.
2. Senior management equates Agile with ‘quicker’ and does not understand any of the other advantages of these methods, e.g., quality, adaptability.
Another mortgage client requested that the IT team stop a large ongoing (waterfall) project and reorganize it into ‘Agile teams’ to shorten the projected completion schedule.
The lower level IT management responded by defining several smaller project teams (which did help some) but arbitrarily committed the new teams to aggressive delivery dates for components which they were unable to meet.
Adoption of a few key Agile techniques was inconsistent. In this case the organizational change was probably necessary, but the expectation of ‘faster’ being an immediate result was unrealistic.
Agile seems to work best when it is implemented from the very beginning of the project without expectations of significant schedule reductions on the initial projects.
3. Lack of time devoted to Data Model design as additional requirements from the backlog are groomed.
One pattern we experienced in several early Agile project was that the individual development teams seemed to focus on their component’s data model but failed to integrate their needs / changes in with the overall application data design group.
The Data group was seen as a ‘delay’ point in the process and teams moved on without reconciling some significant questions/issues.
These cases resulted in later ‘work around’ which resulted in a less ‘clean’ data model.
Ali Adib
About the interviewee: Ali has been a project manager for more than 10 years, for organizations such as Building Blocks Inc. and IGWD Co. He is currently a PM and a Consultant with leadership experience. (Visit Ali LinkedIn Here).
One of the major factors I would like to point out is team collaboration and bringing everyone on the same page.
Technology projects are increasingly relying on self-managed and self-motivated teams. This change in project management trends is calling for more team collaboration and coherence.
Theories such as Tuckman’s stages of group development (forming >> storming >> norming >> performing) have been helpful in explaining some key factors in understanding and leading teams.
It is key for a project manager to understand such theories and utilize that in how they approach and motivate their project team.
As a project manager, I personally resort to a technique that I could call consistent engagement and listening.
By that I mean I actively and continuously try to ask for team member feedback and approval in meetings.
Some meetings of course are shorter and more limited than others. But review meetings are for sure a place for further reflection and spending time on team building rather than merely focusing on the deliverables.
In conclusion, team collaboration and coherence to me is a major quality measure of the project.
If I could advise other project managers, I would vouch for building personal relationships with the team members, understand them as individuals and spend time and attention on building a productive and motivating environment for the self-managed team.
Share your thoughts and questions for the managers in the comment sections below. Contact us if you want to contribute your own experience to everybody in this community.
Sharing is learning. “The happiest people are those who are contributing to the society” — Ted Turner.
