program selection system

This presentation is exploring the answer to ‘why agile projects need strong agile leadership’ based on my experience leading teams on large-scale projects in agile-skeptic environments. It is a review of a top 10 list of values I’ve evolved based on my ‘school of hard knocks’ for building successful teams. Session will explore my 8 years of agile leadership experience and how I see each value as important to a leadership role for teams. Session should challenge audience to define their own value based leadership list.

Top 10 Values Outline:

1. Integrity is No. 1 and I look for this in the people I enter into business with. (Want to enjoy my work!)

   a. Experience Story – Large-scale project sponsor with hidden agenda, committed to quality software objective set with business, but behavior was challenging team on level of software quality needed built to reduce development costs. Lack of sponsor integrity manifested as competing objectives for team and was reducing their trust and confidence in work they were producing. (Automated TDD uplifted development cost ~30%)

   b. Better for projects how? - A leader’s capability to confront the sponsor on integrity issue resulted in escalation and renegotiation with the business owners for resolution. Set the team up to continue to execute what was committed to for the business to be successful.

   c. Impact if not? – Undermines the team’s ability to deliver on committed business outcome as they execute work unaware of all sponsors motives. Leadership role needs to proactively identify and manage these risks, and demand integrity of all project stakeholders.

2. I will not sacrifice/trade away building long-term relationships for short-term profits. (Want to build repeatable business!)

   a. Experience Story – Bidding project teams focused on legacy system replacement project as just a technology migration/rewrite problem, fixed bid proposals did not include estimates for complex project requirements needed to manage integration and change mgmt work to put product into operations. Work sold to sponsors as plug and play work that could be done relatively quickly. Proposed bids were only really covering 30% of total project effort required to get operational.

   b. Better for projects how? - Experienced Leaders look beyond any scope of work as just a technology challenge to get teams to identify and manage all risks for operations to ensure products can be adopted and supported successfully in operations to ensure satisfied sponsors.

   c. Impact if not? - Sponsors are left holding the bag for implementation costs and don’t trust teams to meet commitments. Scenario usually results in a second project and significant more funding to get new product integrated and adopted – or product sits on shelf and is never used.

3. I will not sacrifice/trade away enjoyment in my work over generating dramatic profit growth. (Want to not burn out!)

   a. Experience Story – My ‘just say no’ story. Most corporate environments demand early estimates of work to approve large projects. I’ve done high-level effort estimates for charter as result. Once team in place, you go through planning iterations and team learns more details and solution complexity starts to grow (i.e. software security). I’ve seen teams want to absorb increasing estimates of original work without really testing commitment of sponsors for trading off other priority work.

   b. Better for projects how? - The leader role I’ve played is to ‘tell it all and tell it early’, to sponsors, so the right strategic priorities continue to be validated in managing the detailed work. Change is than managed strategically for the right priorities, verses falling into the trap of just increasing workload, schedule, and cost to deliver on original assumptions.

   c. Impact if not? - Teams assume what was priority when they signed up stay priority with sponsors; this is not true in today’s dynamic corporate environment. Most software projects as a result can over deliver on functionality verses continuing to test what is truly necessary.

4. I want to be intellectually and socially responsible to my customers, family, and community (Want to grow and learn!)

   a. Experience Story – This is the reason most people enjoy Agile teams; Leaders are key in creating the collaborative environment. In Calgary’s hot bed market finding that environment for teams to work closely is not a given. Most office space is maxed out, and leaders have to fight with corporations to get the space and proximity to clients to allow this to happen.

   b. Better for projects how? - Agile teams given the right agile environment grow into stronger teams where individuals can share unique perspectives and grow their discovery skills by working closely together.

   c. Impact if not? - Agile teams without environments created to do agile struggle with a joint commitment to success with team and business. Risk of project falling back into more traditional waterfall tends to result without leader influence on organization.

5. I look to enter into engagements with strong sponsorship and clear authority for me to execute. (Want to be able to do what I promise!)

   a. Experience Story – In large organization where over 300 IT projects are executing, dependency management becomes a large risk. In rewriting a large business critical legacy application, there was a parallel large-scale infrastructure project replacing all our network, server, and database technology. Day one negotiated with sponsors a priority portfolio approach (new to IT process) to manage conflicting work priorities decisions. Top 5 strategic IT projects Identified – both of these in that. Set up weekly dependency meeting with Project leads and architects from these teams to review and resolve work dependencies for resources, change management and release schedules.

   b. Better for projects how? - Schedule managed more effectively, as bottle necks for resources and release windows were planned and manage across projects by priority and risk by leaders. Conflicts were escalated as needed to IT and Business sponsors to manage appropriate impacts.

   c. Impact if not? - Team would be frustrated at a large number of delays due to unavailable operation and design resources needed by team not being available. Project delays and burn rates would escalate as time is lost on dependent work.

6. I recognize individuals are the ultimate source of value and need environment where they can make a difference (I value people over process/tools)

   a. Experience Story – Like most organization there is a learning process for marrying up PMO traditional planning and execution processes with Agile delivery process. In my organization one risk that I regularly mitigated was the value placed on process (resource management process focused on providing project specific skills to team) verses people (looked to build new skills, but find individuals with the right aptitude). Negotiating resources from operations to join team, as part of skills transfer objective was always a challenge, as many had deep technical knowledge but lacked the aptitude to work in a high performing Agile team. As leader take on a coaching role to ensure opportunity is given to individuals to learn new skills, while recognizing and weeding out those who will not fit in.

   b. Better for projects how? - New skills and approaches (TDD) are carried over to operations and reduce overall life-cycle costs for organization by providing forum to train individuals in the organization.

   c. Impact if not? - Teams tend to work around or look to replace individuals not already high performers. Need to be clearly articulated as part of their deliverable for the projects they are brought in for. Leaders ensure the right mixes of talent are managed to ensure all objectives of project are met.

7. I look to attract and mentor talent and partnerships that shares my objectives and values. (Want to work with good people!)

   a. Experience Story – One of my recruitment practices developed over number of years is to look to hire ‘specialized generalists’. It’s a term I use to reflect a desire to attract high performers in a specific skill (i.e. J2EE) who also have solid analysis, database, user acceptance, etc. skills all needed to get the tasks done in each iteration. I see teams with diverse but flexible skills build strong product cross knowledge that can improve quality of a solution.

   b. Better for projects how? - I grew into a leader by being given such opportunities as a developer to grow skills and take on some leadership accountability within a team. We all can name good people who we have ‘paired’ with on projects who taught us a new level of competence or new skill - that we never get from academic training.

   c. Impact if not? - Ego driven or silo-based skill sub-teams limits teams dynamics that can stop Agile teams from achieving higher quality, but also limits each players ability to grow breadth of skills.

8. I look to engage customers through frequent interactions and process transparency – prefer customer collaborations vs. contract negotiations. (Want to earn and keep trust!)

   a. Experience Story – I have rescued a couple of large failing project teams, both times brought in after an external audit had identified a lot of issues. When I’ve reviewed and then re-based both projects using Agile it was clear to me that the both audits main root cause is always a basic breakdown of project communication. Trust is number one, and only happens if a leader parks their ego at the door and works openly with all stakeholders both upward and downward to make things happen. I have been called blunt and direct, but everyone always knows I am an open book with them and tell them the good, bad, and ugly.

   b. Better for projects how? - I’ve found teams respond well as actions reflect an honest effort to ensure that all participants have a voice and they feel supported in their work. Sponsors respond too feeling they have a view into the process and don’t just get the bad news.

   c. Impact if not? – To manage risk I’ve seen some put all the focus on the contract and legalities to the process. Set team up to loose as process takes over the project communication.

9. I look to deliver simple eloquent working solutions over complex and unsustainable solutions (I want to deliver results!)

10. I look to enter engagements that leverage all my talents and grow my business reputation – innovate, solve the unsolved (SWAT), and deliver full-solutions where others won’t. (Want to build my niche!)