Path to Agility 2018 – Central Ohio Agile Association (COHAA), Columbus, Ohio, May 23-24, 2018

The premier agile conference in the State of Ohio; that is a powerful statement! It doesn’t hurt that Ken Schwaber, one of the original signers of the Agile Manifesto has a home and business in Columbus, Ohio, the city that is hosting the conference. Now, for the commercial: The Path to Agility conference was developed to further COHAA’s mission to inspire creativity and innovation in the delivery of value.  COHAA has engaged national and regional Agile thought leaders to provide session content focused on a mix of business, technical, and/or management topics. Whether you are well along the path or just starting out, this conference will help guide you in the right direction. My synopsis of some of the speakers is below.

One of the keynote addresses was provided by April Wensel, a veteran software engineer and technical leader whose varied career spans such fields as education (Zoodles), research (User Testing, Carnegie Institution at Stanford), healthcare (Cognoa), and entertainment (Sony, Playdom). She has also mentored and led workshops with diversity-focused organizations like Hackbright Academy and Black Girls Code. She spoke about compassionate coding; that software projects are failing, not because of technical reasons but due to people reasons. She spoke about awakening compassion at your workspaces, know your key values, and remember the 3 steps: slow down, empathize, and remove suffering while you do your IT jobs. In short, understand the ‘Why’ in ‘What’ you do and make sure it aligns with your personal values.

The next speaker was Allen Bennett, scrum coach with Tata Consultancy. He spoke about the 6 views of the agile manager, which are: empower teams, energize people, align constraints, develop competence, grow everything, and improve competence. He also discussed the 7 levels of delegation: tell, sell, consult, agree: make decision with the team, advise: influence the decision, inquire: ask for feedback, and delegate: let the team work it out. His emphasis was on the responsibility of the agile manger as it relates to overall agile team development. The agile manager must learn to trust, empower, and delegate responsibility to the team so the team can grow beyond its limits.

A former colleague of mine, Dan Rice, discussed agile and continuous delivery. What I liked about his presentation was one, it wasn’t a sales pitch; and two, it was framed very clearly on what continuous delivery is, why a holistic and principled approach is needed to ensure that the organization or department is going in the right direction with their software development and deployments. He gave a story about how at Rally Dev: a customer raised a defect; that defect was replicated as an incident in the development tool the Rally developers were using; a scum team with available capacity, picked up the defect, validated it, and pulled it into the sprint backlog; remediated the defect and checked it in to a code repository; automated unit test scripts were ran against it and passed; once passed, the code was automatically checked into the test environment where automated test scripts were ran against it and passed; then the code was automatically checked into the staging environment where automated test scripts were ran against it with dependent services and APIs; it passed. The fixed code was deployed to production where automated production test scripts were ran against it; passed, and the ‘bad’ code was removed from the production environment, replaced with the ‘good’ code. This occurred in 45 minutes…WOW! That’s what I want my continuous environment to resemble when it grows up. One major constraint with agile software development teams is the missing continuous deployment architecture component that can take advantage of the quick remediation turnaround performed by the agile team. Until that is resolved, companies will continue to have agile-fall frameworks.

My dear friend and colleague at Cohesion, IT Consulting, Sam O’Brien, discussed taking your team to new heights using agile. At its heart, she discussed trusting and respecting the team to perform in ways that they never could have imagined. Be a leader and not a manager. Listen with your eyes, not just with your ears. The agile team needs to embrace the concept of successful failure and encourage new ideas and creative thinking. Her talk focused on whole team development that both the product owner, scrum master, and agile project manager should be aware of when they collaborate with the entire agile team to achieve successful and predictable delivery.

An agile coach and even a scrum master should always guide the team using the agile manifesto as a guide while also understanding, clearly, the environment you and the team are residing in. Scrum software development, or project management, is not structured to be ‘by-the-book’. By its very nature, Scrum is a constant journey of inspection and adaptation. But there comes a time when it’s a good idea for an Agile team (mature or not) to take a step back to review and relearn the foundation principles and practices of Scrum. In other words, have a team “reset” (Nennessy, 2012). A good coach understands presence, be in the moment with the individual, team, or client. Coach the individual, not the problem. If you coach the person they will solve their own problem. Mentoring is coaching the individual but also offering advice, providing resources , telling stories about one’s experience, teaching of models, (selecting from options) (Adkins, 2015).

I hope this provides you with insight into my experiences at the conference. Your comments are welcomed.

Advertisements

Team Productivity Gains with DiPD

Tags

, ,

In order for a company to truly obtain the benefits of Disciplined iterative Project Delivery (DiPD™), the company must allow for a level of maturity to develop through the disciplined use the framework’s best practices. Understand, the resources may have little to no previous disciplined use of an iterative approach. It is recommended that management first determines which projects show the DiPD™ characteristics. A decision matrix should be used to assess whether using DiPD™ will be successful. This is a valuable tool because it formalizes the decision-making process and empowers management and agile project team members to determine the risks and constraints that must be mitigated to ensure the project has the best opportunities for agile success. Too often it is believed that all projects can be iterated, or use agile, while little effort is taken to understand the organizational constraints that may inhibit the effective use of agile tenets and best practices. Using the decision matrix, the organizational risks and constraints can be brought to the forefront and agile project management can iteratively transition management and resources toward agility. This approach also enables management to make an informed decision on which project delivery method to use: traditional or DiPD™. Additionally, the use of the decision matrix begins the risk management process advocated in the Project Management Body of Knowledge™. In this process, the resources management reviews the results of the decision matrix to determine the necessary risk mitigation strategies and triggers, and to select a pilot project. Once a pilot project has been through the decision matrix, the resources assigned to the agile project begin using DiPD™ and are coached using the Whole Team™ approach. This Whole Team™ approach should be used from project to project to achieve the continuous improvement needed to deliver projects Better, Faster, and Cheaper™. Whole Team™ also holds the entire agile resources accountable since every agile resource self-selects on the tasks needed to complete the iteration/sprint in a transparent way. Once these activities are performed, the benefits the performing organization is attempting to achieve will fall in line while improving overall customer satisfaction. In addition to supporting DiPD™, management support is needed to continuously improve the project processes that agile resources are using  based upon the department and/or company’s organizational maturity in agile. Figure 1 depicts an agile maturity model that the project management office can use to gauge a department/company’s current state and plan for its future state.

The department/company should employ servant leadership concepts and create an environment that doesn’t hinder employees from doing their work. It should be noted that agile project teams may experience less productivity as they are initially staffed and coached using the Whole Team™ process and DiPD™ framework. It is recommended the agile project manager understand the Tuckerman’s Group Development Model (forming, storming, norming, performing, and adjourning) as they implement Whole Team™. Once the resources assigned to an agile project reach the performing stage of team development, team collaboration, and an established cadence, will be set and at its best.

AgileMaturityModel

Evolve or Be Left Behind

I continue to find it disheartening when I hear the following words from project managers in the field, “We don’t do agile here” or “All we do is waterfall, agile will never work here.” It’s as if my project management colleagues have not been paying attention to the ever changing business environment. They seem to believe that we’re fighting a war: the waterfall proponents are on the right side and the agile proponents on the wrong site. This is not a battle of good vs evil; not even a view that waterfall is good and agile is bad. This has moved from being a project/software management process to a business model process. Changes in the business world are occurring at a record pace. What once worked before, will not work in the future. Just look at Sears, Toys R’Us, GE, P&G, etc. In order to survive, companies must transform to digital enterprises, and within those companies, PMOs must incorporate capabilities that lend themselves in support of digital enterprises. A recent study uncovered that CEOs are aiming for a 10% annual growth rate in digital revenues (Gartner, 2017). One CEO stated “Becoming digital means more than simply changing products and services. It means changing the way we work. We cannot transform our business model unless were willing to transform our operating model (CEO Fortune 500 manufacturer).” How is a company going to achieve 10% annual growth by ‘ONLY’ delivering projects using a waterfall methodology? By the time the project is complete, the product the project is delivering may not be viable.

Even PMI has embraced a Talent Triangle™ model for its members; focusing on strategic and business management along with leadership. No longer is it business as usual to check all the PMBOK™ boxes as it relates to IPECC (PMPs know what that is). A project management professional must assist their organization in transformative project management; and that means adopting and incorporating iterative and even agile best practices into the way you manage your project. Don’t get me wrong, there are projects where waterfall works best; but an agile framework, incorporated into a waterfall methodology, may increase your delivery rate. It is well documented that using a hybrid project management model, leads to shorter development cycles, higher customer satisfaction, lower bug rates, and quicker adaptation to rapidly changing business requirements have been reported (Cho, 2009).

So, the next time you hear a colleague say “We don’t do agile here” or “All we do is waterfall, agile will never work here.” Kindly say the following, either evolve or be left behind!

Why is Hybrid Agile Such a Bad Thing? The Secret Is That It Really Isn’t!

Tags

, , , , ,

With the movement toward agile software development and agile project management; and with all the training available from certified scrum trainers, agile certified practitioners, and product owner, and with the move of software development to near-shore and off-shore location; why isn’t there any training on how to transition a scrum team from one location to another and more importantly, why does a hybrid agile approach seem so bad? The perception is that if you are not using “pure” agile then you are prone to fail in your attempt to utilize agile to achieve all of its benefits.

But there are times in organizations that leadership decides to go in a direction that is in direct opposition to the agile manifesto and the twelve agile principles. What is a certified [agile] project manager to do? Complain about the lack of “pure” agile commitment? Become a martyr and work against the interests of leadership? No, what a certified [agile] project manager would do is find a way to incorporate the best practices of the project management with the twelve principles of the agile manifesto in way that leads to team growth, increased productivity, and more efficient project delivery in an iterative way.

The agile team decided to use scrum as a framework but with caveats. We had to incorporate approval gates and work with a project management office where I was required to provide status updates, manage change, and obtain approval for budget and release management. This resulted in a hybrid agile approach called DiPD®, Disciplined iterative Project Delivery®. The iterative framework is typical of any scrum development workflow with a few exceptions. One, I did not release at the end of every sprint; two, I needed approval to move from project intake to release; and three, I used documentation.

Starting with the product backlog, also known as a work item list. It contains uniquely ranked stack of user stories so the team can focus on delivering valuable functionality. The ranking of the user stories aids the business stakeholders to decide which functionality is more valuable than others (e.g. MVP1, MVP2, etc). Having MVP2 user stories in the backlog that are not being worked on is acceptable and means the team hasn’t gotten to them yet. User story dependency is included so the team doesn’t work on a user story too soon; this prevents work disruption.

Project Scoping Current State (Business Ideas)

This is important to our team for the following reasons:

  • First time our team is made aware of the entire project.
  • This is formal notice given to our team to proceed with maturing the Project.
  • While change requests have the business needs defined, they do not include all the assets necessary to build out the solution.
  • This introduces the project to the larger team so they can become aware.
  • This identifies dependence among user stories which aids the Product Owner in aligning the Project for future sprints and releases.
  • It provides a high-level estimate of effort of business decision can be made.
  • This is the formal handoff from our team to our client of the analysis performed.
  • Business has the opportunity to resubmit or stop the project.
  • This formalizes the project into executable work for future delivery.

This is where our team provides the estimates, acceptance criteria, and user story dependency back to the Product Owner, and where our client can approve / reject / hold the change request.

 Epic and User Story Maturity (Product Backlog)

This is important to our team for the following reasons:

  • The business analyst works on only approved projects.
  • The Scrum Master can provide awareness of the approved user stories with each of the teams.
  • The Scrum team members have vetted the general requirements and posted needed questions/clarifications ultimately back to the Product Owner for maturity.
  • The content of user stories is complete; all questions/clarifications have been made; and all acceptance criteria are adequate for development and testing to successfully deliver.
  • The Scrum team members understands how to approach the testing of the user stories’ functional and non-functional aspects.

This is where our product backlog is built with a goal of keeping it healthy so work can be continually ‘pushed’ to the team.

 Acceptance (Sprint Backlog)

This is important to our team for the following reasons:

  • Allows our team to fill out sprint capacity.
  • Allows our team proactively make adjustments to sprint work due to changes in resource availability or prioritization.
  • Sprint and release placement aids our client in knowing when an approved project are planned for release.
  • Our client can notify their Partners accordingly.
  • Their Partners can begin assigning resources UAT.
  • Our team is able to ready the approved project and user stories for sprint planning activities.
  • Our team is able to provide a sprint roadmap to the team.
  • Our team is able to provide a release roadmap to LE.
  • Our client is able to realign partner priorities and communicate expectations.

Our client and our team are able to baseline the sprint

Approval Gates (PMO)

Agile, by its nature does not have approval gates. However, in all of the companies I have worked, I have never been able to deploy code to a production environment without having to obtain some level of approval. So in reality, there is an implied approval that has to be obtained before moving forward with a deployment. There are mandatory approval gates my team must adhere to as work moves from idea to working code in a production environment.

This is important to our team for the following reasons:

Gate 1: Defined business ideas

  • Our client is able to filters unviable projects from coming to our team.

Gate 2: Estimation approval

  • Our client determines if business case is relevant based on estimates provided.

Gate 3: Backlog maturity

  • Our client reviews functional solution for MVP and determines if the solution is supporting business need.
    • Our client needs to understand what they are signing off on so it meets the business need preventing rework and future story creation.
    • Our client needs to plan UAT, engaging their partners, aligning external parties around the functionality that is being defined.

Gate 4: Sprint planning

  • Our client defines the priority of work among all projects.

Gate 5: Sprint demo

  • Our team and our client signoff on expected work, the sprint increment, in accordance to quality requirements.

Gate 6: Our client provides our team with release approval.

Both our team and client are assured that modifications work as expected in the end-to-end environment and decides whether work will be released

The Results

There is a lot to like about the DiPD® model. For starters, I was able to increase scheduled release frequency, year over year by 45%. I was able to increase scheduled out of cycle releases year over year by 300%. I was able to add and train a second scrum team using the DiPD® framework and deliver a digital download platform that had failed in a larger company, in 7 months. And finally, I was able to successfully transition development from the U.S. to Bangalore, India in 4 months. There is still a lot of work to do but the hybrid framework is working for my team and my client. And remember, quality is not what you or I deem it is; quality is what the customer deems it is. Specifically, when a product of service completely meets a customer’s need, quality is delivered (PMBOK®, 5th Ed.).

To close, using a hybrid agile software or project management approach isn’t a bad thing. With the challenges facing companies today, following any framework to the letter is a huge risk. You need to incorporate the best practices of project management with the twelve principles of the agile manifesto in way that leads to team growth, increased productivity, and more efficient project delivery in an iterative way. Move to pendulum from bureaucracy to agility…iteratively™.

Product Owners – The Project Sponsors

Tags

,

Too often in agile communities across the corporate spectrum, the majority of the focus is on the agile manifesto, agile framework, agile team, or agile development and testing strategies. Little attention is paid to the agile Product Owner. This paper will describe the importance, and practicality of the role in a realistic agile environment.

According to Mike Cohn’s book, Agile Estimating and Planning (2006), the primary duties of the Product Owner include “making sure that all team members a pursuing a common vision for the project, establishing priorities so that the highest-valued functionality is always being worked on, and making decisions that lead to a good return on the investment in the project.” Cohn (2006) continues in that “the second role of the Product Owner is that of customer.” “The customer is representative of a group or division” that is responsible for providing direction, prioritization, and decision making in support of the development the agile team is performing so a valuable product is built and launched for use by the community, (either a paying public or internal company users).

On the projects that I have worked on there have been strong and weak product owners; effective and ineffective product owners; or engaged or absent product owners. I have also observed that there are no two alike Product Owners. Each Product Owners brings with them their own thoughts, ideas, opinions, micromanagement; and they are always wanting to dictate what gets worked on, when it gets worked on, how it gets build, and how quickly it can development and completed.

The Product Owner role in agile is important because they are needed to do the following:

  1. Be the receiver of new product ideas and enhancements.
  2. Effectively manage constantly shifting business priorities.
  3. Effectively convert business valued product ideas and enhancements into business requirements.
  4. Transfer those business requirements into change requests epics and user stories.
  5. Effectively prioritize and provide guidance to the agile team building the software product.
  6. Willingness and knack to make decisions in moving the agile project forward.

Decisions made by the Product Owner are not made in a vacuum, they are made with the Agile team, business stakeholders, line-of-business and other individuals. Decisions have to be made so team progress can move forward, closure and acceptance of past sprint work can be performed and obtained, and old issues remain in the past. Additionally, Product Owners need to resist the following:

  1. Do not become a bottleneck. The Product Owner needs to make themselves available. If they cannot, have a Product Owner proxy, someone that can fill-in for the Product Owner when they are not available; they are knowledgeable about the system, business and backlog, and is empowered to make decisions.
  2. Do not be the architectural owner. The Product Owner should be the person who has the final say over the work prioritization decisions and not the technical direction. Combining the two leads to chaos and confusion.
  3. Do not lead the agile team. The team is self-led, self-empowered, and are coached by the Scrum Master, not the Product Owner. The Product Owner needs to available to the agile team as much as possible; to have a solid understanding of the business domain and the needs of the business stakeholders.
  4. Be a skilled negotiator. Many large projects have competing and mutually exclusive needs, as well as differing views on priorities. Those large projects also have many requirement and sub-team dependencies. The Product Owner needs to make themselves aware of the priorities and dependencies and be capable of speaking to anyone in the organization as priorities shift; risks have occurred, and maintain stakeholder expectations.
  5. Support and Protect the Agile Team. The Product Owner needs to be a proponent of the agile team, they need to aid the Scrum Master in protecting the team from errand business requirements, differing priorities, and quickly resolving issues that constrain or block the agile team from doing their work.

In summary, Product Owners is an important asset to any agile scrum team. They determine the certainty in an uncertain world of agile software development. They take the naive, the vague and turn it into a valuable product that increases ROI, increases product utility, as they meet time to market goals.

Adding Points to Defects

Tags

, , , , ,

According Pund (2013) during sprints, there are defects that are identified and have varying severities, and the [Scrum] team must make decisions to “fix in the sprint” or “push to the product backlog.” This is typically decided based on whether the developed user story still delivers business value. If a defect prohibits the execution of the functionality, thereby rendering zero business value, is not fixed by the [Scrum] team by the end of the sprint, the Product Owner will not consider the story points “delivered” and the story will not be “done.” The [Scrum] team’s goal should always be to minimize the amount of defects and several ways this can be accomplished is by collaborate with the business analyst’s to understand the requirements, collaborate with quality assurance lead to understand how the testers on the [Scrum] team are planning to test the functionality, and the developers on the [Scrum] team perform unit testing and shares those results with testers. When estimates are determined, rework (e.g. defects associated with the user story) should be included in the estimate for any user story, and is included in the story point estimate. However, there are defects that are identified that are not linked to a particular user story; for those defects, I suggest creating a “feature development” user story for each sprint, providing a story point estimate to it and linking those defects to this user story. An example of this is a defect where a query is CPU intensive. This defect was identified in production and is not linked to a user story the team has accepted into a sprint. This will require [Scrum] team resources to resolve and the team has resolved it. The original estimate was 17 hours and the actual hours was 5. OR another defect where a customer was unable to place an order on the website. The root cause was a data issue. The original estimate was 6 hours and the actual hours was 5. How are either of these defects calculated in the team sprint velocity if user story points are not assigned? I suggest creating a “Application Defect” or “Internal Work Request” user story for each sprint, providing a story point estimate to it and linking the aforementioned defects unrelated to in-scope projects, to this user story. This enables the calculation of sprint velocity for the [Scrum] team; tracks the amount of defects that are identified outside of approved in-scope project work, and allows the team to proactively address defects that are raised in production that may require immediate effort to resolve.

Your thoughts?

Bibliography:

Pund, Prashant (2013). Should Defects Be Considered User Stories. Retrieved from https://www.scrumalliance.org/community/articles/2013/2013-may/should-defects-be-considered-user-stories.

Servant Leadership

Tags

, , , , , , , ,

I’ve been having this ongoing conversation with a college of mine where we discussed the topic of servant leadership. After sleeping on it, he arrived to the office the next day and asked me the following: Isn’t servant leadership …leadership? I replied, yes, but a different type of leadership. Now, the context; our conversation revolved around servant leadership, by project managers, in a traditional waterfall or agile project. His point was – he supports his team by removing constraints, holding weekly, sometimes daily, status meetings; and creates ‘widgets’ for SharePoint that track team milestones, defects, version control, and other activities. He then states that he ‘enforces’ dates for completing milestones on his team and ‘pushes’ his project teams to meet those dates, if not, he works to de-scope the items that will not make a milestone out of his project. My point to him was that “this is not servant leadership.” Servant leadership is about trust: trusting your team to get the work done they committed to. Serving them by protecting them from meaningless meetings, removing constraints they encounter; providing them with the decisions needed to complete their work; and growing them into a empowered, confident, efficient , and predictable team! In Scrum, the Scrum Master, in this case, an agile project manager (APM), is responsible for ensuring Scrum is understood and enacted. Scrum Masters, or APMs, do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master, and APM, is a servant-leader for the Scrum Team. The Scrum Master  and APM, serves the Development Team in several ways, including:

  • Coaching the Development Team in self-organization and cross-functionality;
  • Teaching and leading the Development Team to create high-value products;
  • Removing impediments to the Development Team’s progress;
  • Facilitating Scrum events as requested or needed; and,
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood

Robert Greenleaf writes servant leadership is a management philosophy which implies a comprehensive view of the quality of people, work and community spirit.” Although my colleague supports his team by removing constraints he also does not coach, teach, nor has a project management philosophy that views the quality of people, work, and community. As soon as I told him that trust is a key to agile project management success, he stopped talking, thought a minute, and then said “Isn’t trust coming from the way the project team communicates to business leaders, sponsors, and stakeholders?” My reply “trust comes from when the project team can meet their commitments consistently and become predictable.” “Once the team becomes predictable, the business leaders, sponsors, and stakeholders will increase their support of the team and they will become proxies for the [agile] project manager and Scrum Master. In short, as agile practitioners we need to continue to practice what we preach, educate those who are learning the agile way, and support those as they mature in their learning and practice. As Mahatma Gandhi once said, “Be the change you want to see in the world.” In the case or project management, “be the servant leader you want others to be.”

Agile Project Management Tool, What to use and When

Tags

, ,

I attended a monthly Agile Professional Development chapter meeting last evening in Dayton, Ohio. It was the second such meeting to occur (hats off to Sam O’Brien who organized it). It was attended by developers, business analysts, scrum masters and newly minted professionals (newly minted is defined as my company is doing agile and I’m it)! A topic of conversation was this, which project portfolio management (PPM) tool does your company use? Several in the room said they are using Microsoft TFS, Microsoft Excel, IBM Rational Team Concert, others are listed here. I was struck not by the use of the tool, but by the diversity. If you talk to professional project managers in software development and ask them which tool they use you’d get one of two responses, Microsoft Excel or Microsoft Project. Not to go down the track of comparison and contrast; but, more importantly, the conversation shifted to when to introduce a tool. Several in the meeting suggested not to use a software tool but use an information radiator (more on that later). I shared a story of introducing a tool tool soon to a scrum team I was coaching and the team revolted! The tool was ‘forced’ on the team without their request (a no, no) and after training (1 day), they were off and running. Performing their work on the iteration while learning a new tool was not an easy thing to do. Obviously they had problems using the tool, which impacted productivity, and these problems were discussed passionately during the retrospective. My lesson learned, make sure before the team uses a software PPM tool they are proficient in using more traditional agile tracking tools (information radiator, burn down and velocity charts, product/iteration backlog, buildup charts, etc.) and events (daily scrums, sprint planning, sprint reviews, etc.). And most importantly, make sure the team asks for a software PPM tool to use. This will alert you to the team’s growing self-sufficiency, maturity, and willingness to be transparent. This will also save you a ton of headaches and I told you so! Your thoughts?

Agile and Microsoft Project, Yeah Right!

Recently, I had a conversion with a project manager (certified or not, it doesn’t matter) and he was asking questions in a department meeting concerning agile. The topic that prompted his questions was in response to a request to have PM artifacts that can be used on agile projects. That is code for how can we have the project managers create a Microsoft Project (MSP) plan and give it to managers and senior leaders. One of his questions was how can a project manager use MSP for agile? In responding to his own question, he stated that it cannot be done and it is counter-productive. My name was thrown in as a person who provided a MSP template that could be used as an agile template. Some context, I was responding to a request for an agile MSP template and I just happened to have one J

During the conversation, the project manager that asked the question, once hearing this, turned to me and mouthed, you actually used an MSP plan for an agile project? And it worked? After the meeting he followed me to my desk and I showed him the template. The link to what I created is here: http://www.mpug.com/articles/creating-an-agile-schedule-with-ms-project/. Many thanks to Vincent McGevna and MPUG. I used to be the president of the Greater Cincinnati chapter in the early 2000s. Now, after discussing uses of the template and agile in general, he told me about his experience. He managed agile projects where there was no product owner, Microsoft Team Foundation Server (TFS) was being used, and the project team gave sizes (T-shirt) and resisted provided daily updates. Oh, they had daily scrums, but they did not want to provide the project manager their hours worked that day. They were on 2-week sprints and sometimes they had demo.

Now, I know agile purists will say a software tool should not be used and there needs to be a product owner, scrum master, and daily scrums with progress (in hours) added to the index card on the information radiator; and I somewhat agree. I would add and counter that if you are in a company doing agile and there is no product owner, or proxy, then you are NOT doing agile! If you are in a company doing agile and there is no information radiator visible to the project team  then you are NOT doing agile! Where I will differ, if you are in a company doing agile and you are using a software tool, MSP, Microsoft Excel, TFS, then you COULD be doing agile. Companies are increasing moving toward agility and by necessity will want to try to cram agile into their bureaucratic, document heavy, command-and-control environment. Don’t fret, remember, moving toward agility is an iterative process where you need to incorporate organizational change management concepts. For example, if you are asked, or told, to use MSP as an agile tool, use it; however, make sure you create an information radiator that is visible to the team. Lead the team in iteration/sprint planning where user points are obtained and place them in your tool. Focus more of serving the team and use the tool to support you instead of other way around. In Microsoft Project 2013 you can create a burndown chart . Earlier versions of MSP will create a burndown chart for you but in Microsoft Excel format (e.g. http://blogs.msdn.com/b/project/archive/2007/11/14/we-re-back.aspx). Using Microsoft Excel files can perform the same thing as well as well-known tools.

Regarding the missing product owner, if a product owner, or proxy, is not available I would question is agile the right approach to use for the project. Who will answer the teams questions on the user stories; who will attend the demo and comment on what was product; who will groom and prioritize the user stores, epics, themes in the product backlog, the project manager? For that matter, who will create the user stories, the project manager? If you answer is yes, then you are NOT doing agile. You, my friend, are doing waterfall masking in aa agile costume.

Getting back to the project manager in question, he started to denounce the use of a software tool, Microsoft in particular, and continue to go on about how success using the software tool will not work in his environment. Remember, the goal isn’t to win an argument but to take the opportunity to teach and educate.  Agile software development, and agile project management, is still in its infancy in corporate America and in order to gain converts, you must show them the path and have patience in their pursuit to agility while you guide them to the light! As I’ve always stated, move toward agility…iteratively™.

What do you think?

Leadership in a Hybrid IT Culture

Tags

, ,

I am writing this to discuss the role of leadership in a hybrid culture. Hybrid means, in a project management sense, that IT departments are using a combination of waterfall and agile software development methods to delivery projects. Some call this Agil-Fall or Water-Agility; regardless of the term, what is needed is leadership, whether that is from the agile project manager, developer, tester, or product owner. I have been in IT department where employees have been employed for over 20 years and have the absolutely refuse to lead. Leading is not being knowledgeable about a system, process, or tasks. Leadership is understanding what needs to be done and collaborating with those that it impacts and leading them to resolving the issue, problem, or task. I have worked with very knowledgeable people who will not, nor ever, lead! They can tell you what to do but in the next sentence, say…We Need a Meeting To…

Leadership does not require a meeting. Leadership requires knowledge, fearlessness, humility, and accountability. Knowledge in knowing what is required to complete a task; fearlessness, by involving others so they can work together as a team, even if you do not like that person(s) and even if that means they disagree with your approach and come up with a new approach. Humility in realizing that your approach is not the best one and you support what the group decides; and accountability in holding yourself, and others, responsible for getting it done. Unfortunately, in several IT departments, they are devoid of leadership. From senior executives to hourly employees. We have become culture of kicking the can down the road for someone else to work on or pointing fingers when something doesn’t get done…even when we know what needs to get done.

One of the things I like about Agile is that accountability is inherit in the process. It is very hard to point fingers when you meet daily to give an update on your work. It is very hard to kick the can down the road when you’re the one responsible for completing the work and you know others are dependent on you. Employees need to be empowered to solve their own problems, learn from their mistakes, and hold other employees accountable. Managers need to become more servant in their leadership in support of their direct reports. Leaders are made, not born. Leadership is therefore cultivated, not granted! Your thoughts?