#Agile versus #Agenda – #Rugby versus #Football #PMOT #JIRA #Sciforma #Favre

We were talking the other day about software products that are used to help the execution of projects in either an Agile or Traditional manner. In particular, the discussion was the difference in models used in JIRA versus Sciforma. JIRA follows the Agile or KanBan model while Sciforma follows the Traditional or Scheduled model. The difference between the two models seemed to be grounded in the concepts of whether planning is done in the temporal dimension. (i.e. have we created a preliminary schedule of when activities or tasks would be done and considered dependencies) In fact, you can’t plan in JIRA temporalily without buying add-on components like Tempo-Planner. (Which is probably where they ended up getting the name from)

Rugby versus Football

First of all, when I mention Football I am referring to the American or Canadian version of football. Sorry european and world Soccer fans.

It then became apparent how good of an analogy Rugby versus Football is for Agile versus Traditional.

There were three important observations:

1. 1. 1. Agile isn’t better than Traditional and Traditional isn’t better than Agile. They are fundamentally different games. The methods and objectives are different.
      2. Although both sports have positions and specializations, Rugby players play in 100% of the game (pending injury substitutions), while Football players typically play 50% of the game. This is similar to Football where there is more specilization and subsituting of players.
      3. And perhaps the biggest difference – Rugby is a game more built on flow and reaction, where Football is built more on set plays that are planned and scheduled. (See where I am going with this?)

The point again should be that the games and objectives are different and that one game is no better than the other one.

Agile versus Agenda

My next thought was if we could find a nice, short term for Traditional like Agile that helped to convey the difference between Agile and Traditional like the analogy of Rugby and Football did.

When we look at the definition of Agile, we get:

“relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans.”

It took me quite a while and lot of research, but I think I finally settled on Agenda. Agenda is a term I don’t believe I have heard used when discussing Sotware Development. When we look at the definition of Agenda, we get:

“a list or outline of things to be considered or done“

The important difference here is that an Agenda is a list with a temporal dimension. In addition, an Agenda is perceived to be an initial plan that is to be modified and added to as agreed to. In fact, the first item usually asked in all meetings that have an Agenda, is if the Agenda needs to be modified.

Perfect. Agenda Software Development. Like Agile Software Development, but with an initial planned schedule, outline, and temporal dimension.

Finally a term that conveys the accurate intent of Agile Software Development with a schedule. And that schedule is to be changed, modified, enhanced, and pivoted.

Yeah, Agenda Software Development. That’s the ticket. And in an Agenda Software Development project where Brett Favre, the gunslinger, is the Project Manager. Yea, that’s the ticket.

 

 

Advertisement

Why #athletes make great #Project team members #PMOT #DnD

I was attending a Manitoba Coaches meeting last week we were discussing the topic of Emotional Intelligence in both leaders and teammates. Emotional Intelligence is usually discussed in conjunction with the ‘soft skills’ that people have.

Emotional Intelligence is usually defined as “the capacity to be aware of, control, and express one’s emotions, and to handle interpersonal relationships judiciously and empathetically. ”

There are four fundamental aspects of Emotional Intelligence : Self-Awareness, Self-Management, Social Awareness, and Relationship Management.

Although Emotional Intelligence can be augmented through training and education, there is the acknowledgement that some people have a propensity to have high Emotional Intelligence. The usual Nature/Nurture discussion arose and it was agreed that Emotional Intelligence is usually built through the relationships that people have in their early years.

Epiphany

It was discussed that people who are Emotionally Intelligent are proficient at:

• Collaboration
• Communication
• Accountability
• Independence
• Teamwork
• Leadership
• Problem Solving
• Critical Thinking
• Listening
• Conflict Resolution
• Managing their Emotions

I had an epiphany that team sports is one of the few things that provide consistent, repeated, and evolutionary experiences in most, if not all, of the characteristics listed above that Emotionally Intelligent people excel in. Team mates experience and grow in all of the proficiencies listed above due to the nature of team sports and shared purpose.

In particular, team sports are one of the few activities where peers hold each other accountable, manage conflict, problem solve, manage their emotions, and take turns leading in their own way.

Summary

Team sports are critical not only for physical and mental health, but also project health. Great project team mates have usually been great team mates previously in all sorts of sports.

The lesson? If your children want to be developers, sign them up for Hockey, Baseball, Basketball, and Volleyball. Their future team mates will thank you later.

If they really don’t like sports of any kind, get them to play Dungeons and Dragons. And the computer D&D games don’t count. They need to sit down with friends and learn how to co-operate and deal with looking each other in the eye when they betray or disappoint each other.

That’s accountability – Nerd Style.

The Future of #AI Augmented Project Management is misguided #PMOT #Agile

I haven’t read a Project Management article for a long time that spurred me to write a bog entry within 24 hours. I had that experience yesterday after reading The Augmented Project Manager by Treb Gatte. This article provided an introduction to the interesting application of Artificial Intelligence to the Project Management role.

Treb discussing the three areas of Project Management that could be affected by the application of Artificial Intelligence:

• Planning
• Resource Allocation
• Tracking

Planning

Treb discuss the future of AI Augmented Project Planning:

“Imagine if your scheduling bot generates a proposed project plan, based on the aggregated and anonymized experiences of similar sized companies doing the same type of project. Today, we use tools like Monte Carlo to simulate this information. The bot could incorporate real world data, potentially yielding better results.”

Let that thought percolate while we moved onto Resource Allocation.

Resource Allocation

Treb then illustrates the possible future of Resource Allocation:

“For example, your resourcing bot determines that you need a social media expert on your project on April 5^th for two days of work. It searches data sources like LinkedIn and your public cloud calendar to find a list of suitable and available candidates. Three are West Coast of the U.S., one is in Paris and one is in Sydney. It then automatically reaches out to these candidates with offers. If multiple people accept, it automatically manages the negotiation. Once complete, the planning bot is informed, a virtual desktop with requisite software is provisioned, user login credentials are generated and the specific task information is sent to them. When the job is complete and rated as satisfactory, the bot coordinates with your accounts payable system to pay the freelancer. The planning bot automatically updates the plan and pushes the data to the BI dashboards.”

I’m not sure this illustration involves much Artificial Intelligence as it really if just about integrating with existing technologies and platforms – but I digress.

Tracking

And then finally Treb discusses what the future of AI Augmented Project Tracking might look like:

“Project feedback loops on work are awful. The largest challenge is incomplete data, which results from increasingly fragmented work days, limits of the worker’s memory and tools that rely on human input. It is also incomplete as it serves little benefit to the person entering the data.

Workers are overwhelmed with tasks arriving via multiple communication channels and no consolidated view.

Imagine a world where the timesheet is antiquated. Today, we have systems such as Microsoft Delve that know what content you’ve touched. We have IP-based communication systems that know what collaborations you’ve conducted. We have machine learning capabilities that can determine what you’ve discussed and the content of the documents you’ve edited. This week, we have facial recognition capabilities and other features that can track and interpret your movements. Given all of this, why is a timesheet necessary?”

Opinion

Oh boy, where to start? It seems like most of focus of AI Augmented Project Management seems to be on the collection of data that will make the results better.

• “If we have better historical data, we can plan better”
• “If we have better, faster access to resources, we can complete tasks better and faster”
• “If we have better real-time data on tasks, we can report status and adapt better”

The Problem

The problem was all of these perspectives is they seem to be promoting, advocating, and recommending less human interaction between Project Managers and their teams. If we only had AI augmented Project Management, we can go back to our closed doors and avoid the pesky human interactions. Agile Project Managers realize that human interaction is he crucible of project success – AI Augmented Project Management seems to have forgotten that.

Yes, planning is hard.

Yes, resourcing and building high-performing teams are hard.

Yes, tracking and adapting the project is difficult.

But the answer is more interaction, communication, coaching, caring, and collaboration. Not less.

I’ve even seen another article promoting that chatbots could help to get status updates from team members. Oh yeah, that will greatly improve communication of information. Developers will just love getting the impersonal 9:03 am greeting of “What are you planning to do today, what did you complete yesterday?”

Summary

I believe the idea of AI Augmented Project Management will end up on the trash heap with the CASE tools that were going to replace developers in the 80’s, Artificial Intelligence can assist augmenting individual competencies, but not replacing team communication, interaction, and problem solving. Perhaps, there is a role for Artificial Intelligence in reviewing plans and highlighting possible areas of concern regarding scheduling or estimation that a human can review. But the automated  creation of plans, resource allocation, task assignment, and task tracking is misguided.

The idea that worthy Project Manager work is stakeholder management,  but not team collaboration, engagement and communication is wrong.

Software Development is a team sport, and requires collaboration, communication, and engagement to plan, resource, and adjust. The idea that you can broadcast the skills you need and just drop a resource in to do a task and not worry about culture, fit, team dynamics, and personalities is pure hubris. These are people working on complex, nasty problems. They need time to gel, bond, and collaborate.

Sports is frequently identified as an area Artificial Intelligence has helped. Absolutely. Artificial Intelligence can refine skills like throwing a football and shooting a puck. Assisting in team dynamics and planning remains elusive. Coaches still call the plays and adjust plans. Even coaches that leverage technology realize that…

 

The #Two traits great #Managers have #PMOT #Coach

Managers and management in general usually have a bad reputation. That is probably  doubly so for middle managers. These roles are usually the first ones identified for job reduction and attrition. Why is this? Truth be told, it is an exceptionally difficult role that not many people excel at. Usually people excel at one aspect or another of the role, but not at all of the aspects.

What makes a great manager?

So what makes a great manager? The manager must be an agent for the decisions and directions that come from above AND be an advocate for the teams that ultimately execute the work. Unfortunately, most managers tend to primarily identify with either agency or advocacy, but not both. Most managers focus their effort on managing the teams, but not managing the executives. Managing-up is one of the most difficult and challenging skills and most also be welcomed by the culture of the organization.

It is a delicate balancing act that experienced managers deftly handle – the right balance of agency and advocacy that promotes high-performing teams both above and below them. If this balance is not appropriate the manager usually defaults to just concentrating on one or the other – to the detriment of both executives and teams.

But when a manager has the right balance, they build credibility with both executives and teams. Once that credibility is built, the managers are then invited in to discussion and designs to influence, contribute, coach, innovate, and inspire both executives and teams.

Two Traits

The two traits that a manager or Project Manager must have to reach this level of proficiency are Business Knowledge and Realization Knowledge.

• The manager or Project Manager must understand the business domain, business strategy, and culture of the organization they are an agent for. Why does the Business Exist? What is the Strategic Plan? Who are their internal and external clients? Who are their competitors? What are their values and principles?
• The manager of Project Manager must also understand the realization domain and implementation processes as well. Whether the realization practice be accounting, engineering, software development, or teaching – the manager needs to understand the work and the profession. How do we implement changes? What professional skills are required? Who are the experts and why? What are the industry-accepted best practices? What are the new methods and technologies on the horizon? What practices are no longer being used?

Only when the manager has both these traits, will they have the credibility to be invited in, contribute, coach, influence, and help to innovate the strategy of the business and the implementation of business initiatives.

This is a not an easy combination to achieve and the lack of the these traits can lead to just ‘paper-pushing’ as the manager doesn’t have the credibility or knowledge to do more. Most times a manager may have one or the other trait and while this is beneficial, true high-performing teams arise when the manager or Project Manager has both.

Our responsibilities as managers is not to just perform administrative duties, but to relentlessly inquire and learn both about the business domain and the realization domain. Only then will the manager be an integral member that makes the executive and team members better by coaching up and down.

How to #Innovate – an Example

How to Innovate

In my last post, I was stressing how encouraging Innovation is not simply about layering Innovation over existing processes and culture, but how it really is a change management project about changing the culture of an organization. If you missed it, you can read it here.

Reading through the Winnipeg Free Press today, I was provided with an example of how Winnipeg is not really committed to Innovation, but only interested in it.

The Example

So it turns out that the city of Winnipeg, is building a new library named in honour of former Mayor Bill Norrie and his wife Helen. This is a good announcement for something that is really needed. You can read the story here. I listed the CBC link instead of the Winnipeg Free Press because the Winnipeg Free Press has a pay wall. (but that lack of Innovation is for a later post at another time)

I say this is only a good announcement because libraries are always good things and the library will be addressing some shortcomings in other libraries in regards to accessibility, natural light, and outdoor spaces. And it is also beneficial that it will be connected to other facilities and public transportation. But it could have been so much more if Winnipeg’s leaders were committed to Innovation.

I’m reminded of the old joke about how the chicken is only interested about breakfast while the pig is committed to breakfast. Winnipeg is definitely interested in Innovation in Libraries as they have created Maker Spaces among other Innovations at some libraries.

How could they be committed to Innovation you ask? Well I’m glad you asked.

Empowerment

A key factor in Innovation is breaking down the hierarchy of control and empowering others – changing the culture. This involves those in control letting go of their authority. They no longer ‘approve’ the Innovations recommended by others and plan and design in isolation.

How would this look?

1. Libraries are a key service provided by the municipality and would be an area where the city can control Innovation if it was interested. So it seems like a very good example.
2. Define a Library Strategy of what Winnipeg wants to achieve with their libraries. Start with the mandatory items that are legislated like accessibility so it is clear what is non-negotiable.
3. Create working sessions and involve City of Winnipeg Council, City of Winnipeg Administration, Citizens, Universities, Educational Professionals, and children to help to define the Strategy. The only existing Library Strategy I could find was one to discuss whether we should build or lease libraries. That just made me sad. 😦
4. Once we have the Strategy, have the same group define what the short-term and long-term objectives are and how we will measure if we are successful.
5. Once we have the Strategy, Objectives, and Success Factors we can innovate and discuss the features that satisfy the Strategy best. A Library has to be more that just building with books inside. For example:
   1. What is the content we should provide?
   2. Ask the current administration how libraries can be improved?
   3. Ask City Council what their constituents are asking for?
   4. Ask the Teachers what is lacking in the libraries currently?
   5. Ask the students why they study at a Starbucks instead of a Library?
   6. How does the Library change with e-readers? Do we rent e-readers with content? Could we offer books in multi-languages easier this way?
   7. There is a movement to more group spaces in other libraries. Should we dedicate more group spaces?
   8. What other services could be partnered with Libraries?
   9. How do libraries change with Social Media? Do they?
   10. Are libraries next on the cusp of a Blockbuster/Netflix moment? Should we investigate streaming content?

These are just a few ideas. The key is to communicate what you want to achieve and then listen to your clients.

And here is the scary part, implement what they recommend. Majority rules!

That is the scariest part of Innovation. Executives still want to ‘approve’ innovations. A culture of Innovation believes that everyone has great ideas and majority rules. There is no knowing where the great ideas come from, but it is likely to come from those closest to the value.

Usually announcements like this are made once all those things are decided.  Getting everyone involved early and empowering them with real decision making would make these announcements great.

 

How to hire a Chief #Innovation Officer #FTW

Innovation

Innovation. We want to innovate. Everyone tells us we need to innovate. Everyone else is innovating and we need to keep up to them. If we don’t innovate we will be left behind. To this end, many companies are hiring Innovation Officers, Innovation Directors, or God forbid a Chief Innovation Officer. Some companies include Innovation in their name hoping to imply they are innovative just by having that name. Governments are adding Innovation to a Ministers Portfolio name in the hopes that they may generate Innovation. Even in my own city, Winnipeg, they hired a Chief Innovation Officer and are trying to innovate.

Problem

So what is the problem? Surely it is a laudable goal to innovate, improve, and excel? Absolutely it is. The unfortunate fact is that the way people are addressing innovation has very little chance for success.

Why

Innovation processes can’t simply be overlaid on a corporate structure that wasn’t innovative in the past and Innovation will occur. In the case of the City of Winnipeg, a call went out for people to submit their ideas and those ideas would be reviewed by the Chief Innovation Officer, the Chef Administration Officer, Chief Corporate Services Officer and Chief Transportation and Utilities Officer.

Oh boy, where do I start on this one? Lets use bullet points:

• The people at the highest level are talented individuals but probably are not aware of Innovations required throughout the corporation. They are going to miss a ton of great ideas.
• What is the Strategy that Innovation is required to address? What are the objectives? A general call for Innovation will probably generate a lot of wasted time as Innovations are submitted that aren’t a priority and people will wonder why their submissions weren’t chosen. (Unless a meeting is held to do a retrospective on every submission, but my experience is that doesn’t happen in these Innovation Beauty Contests)
• If the Culture of the corporation was not open to ideas in the past, people may be hesitant to submit ideas formally via email. Some ideas may highlight inefficient processes that could implicate co-workers. So people are likely to just not respond. (especially if they would implicate supervisors and managers who hold power over them)

How to Innovate

So how would I create an Innovation Culture?

1. Just that. Realize that it isn’t about generating Innovations in your current corporate structure. Innovation is about a change project to change culture profoundly.
2. Invite people from across the corporation to participate in the Strategy Creation. If that isn’t feasible, at least communicate the Strategy in a meaningful way after it is decided. (i.e. a face to face meetings and not just sending a Strategy document out for people to read)
3. Engage the people who are interested in face to face Innovation meetings where groups can submit, discuss, and shape Innovation ideas with their co-workers. These sessions need representation from front-line staff, supervisors, managers, and executives.
4. Ongoing efforts to create a culture that is a safe culture for new ideas and suggestions. This is important. You can’t have Innovation if you don’t have a culture of Safety. You can’t have an open door for Innovation and a closed-door for everything else.

This would be a start, but it isn’t guarantee. It takes hard work and lots of communication between people and time. But there is no shortcut to Innovation.

Especially hiring a Chief Innovation Officer.

 

 

Is my #PMO #Agile?

I recently presented on Agile Project Management Offices at Canheit 2018 at the lovely Simon Fraser University Campus in Burnaby. The conference was extremely well-organized and had many great sessions. The only complaint I have is that there was no bacon, but that is a small point. 🙂

In putting together my presentation, I had a to think about what makes a PMO Agile? We all know what makes a Project Agile, but how did that translate to the PMO? To further complicate the matter there are different types of PMOs. There are PMOs that deliver templates, those that dictate a methodology, those that provide a Career Centre for wayward Project Managers, and others that try to do all of these things.

I’ve always felt that an Agile Project at its heart does three things:

1. Provides Brutal Visibility
2. Minimizes Inventory
3. Uses the Brutal Visibility and Minimize Inventory to deliver more value

Agile PMO

On first blush, those factors translated pretty well to an Agile PMO. But I still had to ask myself how did the Agile PMO deliver more value? I looked at Agile Projects again and how do they deliver more value? The one word that kept popping in my mind was that Agile Projects use Brutal Visibility and Minimal Inventory to Pivot or change the direction of the project. More important than that, the Brutal Visibility and Minimal Inventory allow the Pivot to be done in ‘an informed manner with limited waste’.

So ultimately I felt Agile Projects or Agile PMOs do three things:

1. Provide Brutal Visibility
2. Minimize Inventory
3. Pivot in an Informed Manner with Minimal Waste

Summary

So for projects, this means Pivoting to allow the scheduling/trading/exchanging of features to deliver the most value.

For a Project Management Office, these means Pivotting to allow for the scheduling/trading/exchanging of projects to deliver the most value. And for Project Management Offices this means understanding the best way to allocate people and budget to the work required. In my expeience, budget is far easier to allocate than people with the team dynamics and role mixtures that are required on a project.

Sadly, most Project Management Offices struggle with Resource Management and manage resources in a series of Excel Spreadsheets that are usually out of date by at least a couple of months. When Project pivot decisions are required, the Project Management Office is guessing at people’s true allocation. More importantly, the Resource Management system usually doesn’t track actual hours that would indicate the leading edge of problems on projects.

To be a true Agile PMO, a Resource Management system must be used where your Resource allocation is current and the ability to Pivot exists every day. We recently implemented a Resource Management solution and the data being generated/captured is just showing how impactful it can be.

Now how many of our Project Management Offices could be considered truly Agile?

You just have to work #here #HigherEducation

Here? Specifically? Well kinda.

But I’ve always said that it is best for an individual to have a breadth of work experience. In the past I have mentioned that I felt it was important for a person to have experience in a private company, a government agency, and a consulting company for a least a couple of years each. Each one of these models operate very differently and distinctly. And the interesting things is that no one model is better than any others. Each model has different drivers and priorities that drive their behaviours.

University

I’ve now found a found category to add to the list – University. University is a bit of a mix between Private, Consulting, and Government, but it also has characteristics present in none of them.

University does have the drive to improve and innovate from Private, the challenges of people coaching and change management from Government, and the lack of direct authority in a Consulting environment where you need to rely on the your skills as a facilitator, negotiator, and influencer.

But at University you need to do three models all at the same time and realize two additional truths:

1. Every Faculty and Department are/can be a company on its own. There are limits to any authority over them so the focus really need to be on bridge-building and selling the benefits of your ideas.
2. University culture is about questioning. But rather than questioning to show their own knowledge, questioning at University are done to make the idea better. While this can be frustrating, once you realize the questions are following the method of Socratic Questioning,  they are easier to accommodate.

Oh yeah, and with the need to facilitate and influence and answer people’s Socratic Questions, things just take longer….

But the solutions and ideas are really better.

 

First deadly sin of #Agile

I’ve always thought that for all that Agile got right, it almost got the same amount wrong. And most of what it got wrong had to do how it distanced the client from the project team.

Surprised?

Remember that although Agile was promoting co-located teams, the clients certainly had a different status than the other members of the project team. I’m still amazed that the Scrum segregation of clients and team members into chickens and pigs is tolerated. The basic premise is that although the clients are interested in ‘breakfast’ they aren’t as committed as the ‘pigs’. This of course is ridiculous and in many projects the clients have more on the line than the development team. But the most disappointing thing is that Agile seemed to inherently promote a hierarchy. Even outside of Scrum, Agile still seemed to confuse who defines value and the project team typically over steps their bounds and decide for the client. For example, the No Estimates movement deems Estimates a waste repeatedly although the only people who can determine what is waste are the clients.

Semantics

Much of this can be tied up in Semantics. The terms of Client, Customer, Business User – all separate.

It wasn’t until we were talking terminology in a more traditional project structure that we decided there was a much more appropriate term:

Colleague – ‘A person with whom one works in a profession or business.’

Or even better, from the Latin collega or ‘partner in office’. Finally a term that does not imply a hierarchy and instills the promise of a partnership working toward a common goal.  All colleagues working to create the highest quality solution to a problem.

Colleagues delivering frequently to minimize Inventory and shorten Feedback Loops.

Now that is Agile.

 

My #Agile Breakup

So it has been 11 months now since I’ve seen Agile. How has it been? To be honest, I haven’t missed her. I really haven’t. What has been made clear is what Agile is and what she isn’t.

First Date

I guess Agile and I started dating in 2006. We both were interested in each other and then I was able to arrange for Yves Hanoulle to be the keynote at the Software Development and Evolution Conference I was helping to organize in 2011. Yves had a great presentation on the Agile Mindset that was brilliant. I must admit I only realized how brilliant in the last few months. I think I did what many people have done when they encounter an attractive person coming out of a bad relationship. I moved too fast and fell too hard after being with Waterfall for too long.

The Agile I met was a collection of interesting, valuable methods. There was the concept of the Agile Mindset that Yves and others were promoting with wisdom. But I fell into the same trap as many others. I was going to propose to Agile and she would be the only methodology for me. All projects would be Agile. If clients didn’t like my new girlfriend, then they could go elsewhere.

Agile was a Methodology. I was sure of it. I would exclude using all other methodologies while Agile and I were serious. I would create an Agile Methodology by combining methods and practices. I would read and author Agile papers and presentations where we routinely challenged and chastised each other for not being ‘Agile enough’. I looked for the Agile complement for all waterfall or traditional methods. No matter the project, I promoted the Agile method.

For those of you keeping score at home, the PMBOK isn’t a methodology as well. Similar to Agile, it is a listing of processes, procedures, and knowledge that can be applied. But it is not prescriptive and does not provide governance on how to apply the methods and practices. Many companies take the PMBOK components and create their own methodology from it though.

But what about Scrum you ask? I’d say Scrum is an incomplete methodology. Although it does provide a methodology for the iterations on a project, it does lack guidance and governance in relations to the business case and pre-project intake process. Scrum also lacks guidance for the larger portfolio and enterprise governance concerns.

My Agile Mindset

My mistake was trying to take a collection of methods and assume a methodology exists. A larger mistake was then losing my Agile Mindset of constantly questioning the Agile methodology for value. That is my biggest complaint about Agile now. Many proponents seem to have lost the Agile Mindset of constantly questioning the best method to use on each project. Everyone is just promoting more and more ‘Agile’ methods without confirming that the method returns the most value for the clients. See the No Estimates discussion for this. To blindly promote no estimates for all clients does not represent an Agile Mindset.

I was going to say I’m just as Agile now and I was before, but that statement shows a non-Agile mindset – Agile is not a methodology to achieve. Let’s just say, I feel my projects achieve the maximum amount of value for client by using the Prince2 Methodology using Agile methods and practices were appropriate. Everyone I’ve worked with sees the value in Agile methods and are eager to work with them. The concept that you have to buy the entire Agile Methodology to use an Agile practice is misguided.

I mention Prince2 because that is what we use at the University of Manitoba. You could replace it with whatever you use at your company and then search where you could use Agile methods to return more value. The more I use Prince2, the most I think it is one of the best methodologies I have used though. Highly recommended.

Use an Agile Mindset, Agile isn’t about the Methodology it is about getting better little by little.