“How do I convince my CIO to switch to Agile?”

“How do I get executive buy-in for Agile?”

“How do I sell Agile to Senior Management so I can run projects the Agile way?”

Recently at an AgileWinnipeg meeting, an awesome perspective on this discussion was provided by Mark Kulchycki. Mark provided the analogy that proposing Agile to your CIO and expecting him to switch was akin to running a marathon cold. I think his exact phrase was that “you would kill yourself”. Expecting a sane and rational person to switch 100% to a new radical process(from their point of view) is not likely. Mark took the analogy further and suggested that you need to start in small steps in Agile just like to do in training for a marathon. Once you get trained in the smaller races and show that you are proficient, you can add more time and difficulty until you can eventually run a marathon.

This ‘selling’ of Agile is exceptionally difficult. Agile is a set of principles and practices that should be customized for each situation. This very nature makes it harder to propose and convince people as there are not a set of consistent templates and cookie cutter process that you are recommending to be used every time. Senior Management get concerned when you present a solution with a lot of ‘well it depends’ phrases in the solution. Many people interpret this flexibility as incompleteness.

How to convince your Executives

1. Build Agile awareness and ground it in the business benefits

Many times I see Agile proposed primarily from the Software Development process. While this is important, this is only one half of the concern of Senior Management. The other side of the coin is the impact and benefit on the business. An important first step is to build awareness about the business benefits Agile can return.

Oh yeah, and don’t call it Agile. Some people may have a bad experience or have read an article in CIO Magazine that explained Agile was Cowboy Coding. Just label the processes as discovering better ways and discuss the business benefits. I mean who wouldn’t want to deliver business value frequently and eliminate waste? What CIO could argue those facts?

2. Earn small victories, but not too small

Gain acceptance to try out some Agile practices on small projects to show their benefit. Focus on the business benefit that can be realized. Pick a project that will benefit from frequent and early delivery. Pick a project where the client is excited about the use of Agile practices and being able to work side-by-side with the development team. Be sure to also set expectations with the client as to how the delivery in Iterations will work and that the first delivery will not have the complete solution. Find a client that will work as a partner.

Remember, no company is going to switch from big-bang, waterfall projects to totally Agile projects just by reading books and discussing the merits and stories of the benefits other people have realized. Get over it.

You will need to show how the principles translate into real results for your project and company. Build small and then build out. You can’t run the marathon immediately.

Oh yeah, make sure the project isn’t too small so that no one notices the benefits Agile has delivered.

3. Choose your team carefully

Choose your development team as carefully as you choose the client and project. An Agile project requires people who are more comfortable with change, vagueness, learning, new processes, and working side-by-side with the business and each other. Some people are less comfortable with pair-programming, daily stand-ups, co-location in a noisy room, and cross-functional teams. This isn’t a bad thing, but know your team and know their preferences. Although many people won’t state it, Agile isn’t for everyone. Some people prefer Agile practices more than others. Choose your team wisely to maximize your chances of success.

4. Complete and Repeat

Complete the project and repeat with other projects. Try to do more and more Agile practices with each project. Demonstrate the added value with each and every project. Learn from the projects and improve. (just as you learn via retrospectives as the projects are executing)

Summary

It is probably impossible to switch Senior Management from Waterfall to Agile overnight. But with small wins and increased distance training, you company can run the Agile marathon as well. Just like a marathon, the important part is the training that allows the marathon to become routine.

P.S. finding a good coach never hurts as well.

I have had some great discussions recently on what an Agile leader is and what makes a great leader. Unlike stereotypical leaders, Agile leaders are not expected to make all the decisions and define the vision for the team. Those responsibilities belong in a more standard command and control project structure. So what then is an Agile leader? What do they do?

I reviewed the people who I believe are exemplary leaders. They were from a variety of sources:

• Wadood Ibrahim – Protegra
• David Angus – Chamber of Commerce
• Steve Yzerman - NHL Centreman
• Ray Lweis – NFL Linebacker
• Neil DeGrasse Tyson – Astrophysicist
• to name but a few…

Three statements

My opinion of an Agile Leader and leaders in general are summed in three simple statements:

1. Honest care and concern for all team members and clients (the Heart)
2. Relentless effort to increase the value to the client and team members (the Mind)
3. Relentless hunger to learn and improve. (The Soul)

Honest care and concern for all team members and clients

One of my favourite leadership quotes is:

“Before people care how much you know, they need to know how much you care”

I must admit I do not know whose quote it is, but I believe it captures the heart of leadership. Before anybody will consider following you, they must trust you. And to trust you, they must understand that you honestly have care and concern for their opinions and well-being. Can you direct people without this trust? Sure you can, but we call these people managers instead of leaders. These are people who direct by position instead of leading by trust.

Relentless effort to increase the value to the client and team members (the Mind)

Great leaders I have worked with all share this relentless effort and work ethic to make the team and project the best that it can be. The video below from Ray Lewis shows the effort level that defines a leader:

Ray Lewis-Effort

Great leaders are able to relentlessly improve the value to the client and team members without making those decisions for the client and the team members. This is an important distinction to make. The leader can not make the decisions for the client and team members and expect them to follow. Great leaders have exceptional influencing skills, but also believe that the client and team have the ultimate decision on what value is and what improvements make sense. Great leaders do not get caught up in making improvements themselves, rather they focus on the facilitation with the team and client to make improvements.

Relentless hunger to learn and improve

Great leaders have an open mind to all new ideas. They seek on new ideas and concepts. They seek to understand before commenting. They honestly believe that none of us is as smart as all of us.

One anecdote I love that illustrates this point is about Ray Lewis. Ray Lewis had just learned that Mike Singletary (former Bear’s linebacker) was the new defensive co-ordinator for the Baltimore Ravens. I believe Ray Lewis had been in the league for over 5 years and at this point and had already made the Pro Bowl and possibly already won a Super Bowl. The first day Mike Singletary showed up for work, Ray Lewis was in his office at 6:00 am asking him to teach him. That demonstrates the hunger for improvement and leading that true leaders have better than any other anecdote or quotes I have heard. I can imagine the impact this had on the team’s other players when they heard of this hunger to learn.

Summary

I believe Agile Leaders and Leadership have the three characteristics of Care for the team, Effort to improve, and hunger to Learn. All the people I believe to be great leaders share these characteristics. In retrospect, these characteristics don’t define great leadership – just great team mates. Maybe that is all great leaders are? – Thought for another day…

I believe that the project to build Investors Group field is a major undertaking that has many complexities that everyone outside of the project are probably not aware of. In this way it is very similar to the issues on a Software Development project which look very simple to fix from the outside. This blog contains observations of someone from the outside without the knowledge and context on the issues.

The blog post is not intended to be negative or pessimistic in regards to the building of Investors Group field, but I am struck with how certain aspects of the project to build the stadium has a direct relationship to what can happen on a Software Development project. It isn’t so much the issues and under-estimation that has caused me to see the similarities, but rather how the issues have been communicated. Every project will encounter issues, but I find the great projects excel in the communication of the issues.  

Communication

This has to be the number one rule for all the great projects I have been a part of. No one likes to be the bearer of bad news, but bad news delivered early and promptly is usually met with a short-term negative reaction followed by long-term understanding and buy-in. When the ground was broken in May 2010, but excavation was not started until September 2010 the project was already behind the schedule for what the general public thought the construction schedule was. Add to this the subsequent delays caused by other factors and the completion date is now 90 days behind schedule. Perhaps the people on the project were kept up to date on the schedule, but from the outside it appears that the communication to the real stakeholders, the public and season ticket holders, was not done until recently.

I can’t help but think that if the public was made aware of the delay early on, I believe the reaction would now be far more understanding. In this way, I think it is very similar to all stakeholders on Software Development projects. The mantra always is: “Just don’t surprise me”. Unfortunately the fans were surprised by a delay of 3 months after continued assurances the project was on track.

In discussions published about what would happen if the new stadium was not ready in time, there seemed to be an unwillingness to even consider playing games back at CanadInn Stadium. While this may have been a communication designed to keep the pressure on to meet the date, it again resulted in a lack of communication to the true stakeholders. The season tickets holders wondered why the team would not even consider playing back at the old stadium and it appeared from the outside that a contingency plan did not exist to play at the old stadium. I believe that contingency plans existed all along but the problem is that without communication, the dark side of communication appeared on the scene…. perception.

So with the lack of communication, the public made up their own reality in what they perceived could be happening…. and well you know the rest. 

Summary

I harken back to the Mike Kelly days and think of how he used the phrase “Control the message”. I think in Project Management the phrase to use is “Get ahead of people creating their own perception”.

The stadium will be awesome when it is created. I look forward to attending many games and hopefully hearing many updates over the summer months on how the project is progressing…

Now if someone can just explain why they didn’t keep Donny Oramasionwu, I’d be a happy man…

Our first thought was to again reinforce that Agile is about finding better ways, no matter where you are on the Agile/Waterfall continuum. Our second that was to reinforce that using Agile in a non-Agile environment should not be viewed as a lesser implementation of Agile. As long as the client is getting the most value from the application of Agile, it should be viewed as successful as a more pure Agile project.

What is Agile at its heart?

When we discussed what Agile is at its heart, we came up with two things:

1. Reducing Inventory (Whether they be documents, features, or wasted processes)
2. Shorten Feedback Loops (On deliverables and on the use of features in Production)

Who decides Value?

Often times I believe we as Agile professionals get caught up in determining what is valuable for our clients. This was a major fault with the Waterfall processes, and I fear Agile in falling into the same trap. In the past, Waterfall projects had less frequent interactions with clients and the projects and professionals were expected to make decisions for the business. One of the first benefits of Agile that I saw was placing the full determination of priority and value clearly back into the hands of the client. For too long, projects had wrestled the full determination or priority and value away from the clients and the processes Software Development projects used were considered mandatory and not open for debate.

But now I fear that we are slipping back into that black and white Worldview. But instead of the Software Development professionals informing the client that we know what is best for them, Agile Software Development professionals are informing other Software Development professionals that we know what is best for them. And if some projects and professionals are not as Agile, they clearly have bastardized Agile.

Three statements I heard in the last week were:

• Business Analysts have no value
• Estimates have no value
• Documentation has no value

From whose perspective? I would be hard pressed to find any client I have worked with in the past twenty years that would agree with these statements. I agree that doing documentation and estimates excessively can provide limited value, but in the end the person that determines that value is the client.

The statement that we came up with for the presentation speaks for itself:
“More Agile processes can deliver less value for some clients.”

 We present at the Agile Winnipeg Users Group on May 10th. Hope to see you there and hear your questions and thoughts.

Our solution

Borrowing from the talking stick idea of the Northwest Native Canadians, we decided to implement the use of a token to grant rights to an environment. You can find out more about the Talking Stick by following this link.

I have heard mention of using a talking token in stand-ups to energize the meetings. So our idea is to have a football for each environment. Possession of that football is required for all demos, deploys, and changes to all environments. Possession of the football can be reserved ahead of time or granted on an ad-hoc basis. You can’t take the football away from the other person though, it must be given willingly. Essentially you need the football when you want to change an environment or prevent an environment from changing.

I’ll report back on how the football concept goes. It is just another opportunity to make work fun in the middle of a rapidly evolving project.

Our Board

Our board is what I would consider a relatively standard board. (Of course, I would have that position) We have limits for each of the columns on the board and the columns are:

• Open
• Analysis and Design
• Development
• Testing
• Done

We also have rows that help to categorize the features. I have seen people create rows for individuals, but we wanted to keep it at a higher level to not imply that one person ‘owns’ the feature as multiple people will be working on the feature. (Note: we use the term feature but it equates to a User Story or a small collection of User Stories)

The Diversity

1) the level of Feature/User Stories that you track on the Kan Ban board can vary greatly. This was somewhat expected.

2) Can cards move backward? In my thoughts, I would move the card back to analysis if more analysis was required and then move it back to development when coding can resume. My friend would keep it in development the entire time. I would state neither is correct or incorrect, but it is interesting how we both modeled our board to get us the information we wanted. I primarily wanted to know what type of work was being done, while my friend was more interested in showing how long it has been worked on. (Cycle time) Either system can probably provide both, but it is interesting as to what each person’s preference was. The driving factor in this difference might be our background as I am more project management focused, while my friend is more developer focused.

3)  Defects… My friend would create every defect encountered as a new card while I would consider the defects part of the original card until it has been accepted. (Once the work has been accepted and considered done, then any subsequent defect would be considered a totally new card) This difference was perhaps the most surprising as I just assumed that we would consider the feature in totality and creating a defect as a new card would perhaps give the false impression of done. Perhaps this is another indication of both of us using the board for different primary purposes. Again my friend was focused on flow of the work, while I was using it to manage done according to the stories we communicated to the business users.

Summary

There is no right way or wrong way to implement Kan Ban. That is one of the reasons for the easy adoption. I encourage you to try it and talk to your co-workers and friends. You may be surprised with the variations.

On my latest project, the client had already chosen Mingle. I was actually looking forward to using a different Agile project management tool so I could compare and contrast. After being able to use Mingle for a while on my projects here are my observations:

Kudos!

• I love that Mingle and TargetProcess both allow you a ton of power to customize the product to fit your current situation. Both TargetProcess and Mingle also implement the concept of workflow. This is very powerful and if anything I would suggest that Mingle’s transitions are a more elegant solution.
• Although Mingle seems easier at the start, it actually took me longer to understand the structure and process and what structuring my cards in a certain way really meant. That said, once I understood those implications, Mingle provided more power and functionality.
• The flexibility to make every object in the process a card and define the attributes for those cards is a very powerful metaphor.
• The only place Mingle seems to be awkward is when you are creating and managing by Iterations. The process and functionality didn’t seem to flow as nicely as it did in TargetProcess. In hindsight I believe TargetProcess is perhaps better suited to Iterative execution of projects where Mingle is better suited to pure Flow execution of projects. Once we dropped the concept of Iterations and just focused on the Flow and WIP, the Mingle template and process was much simpler and easier.
• MQL is an interesting beast. Once you understand what the basic syntax and functionality is, it provides a lot of power to be able to generate reports and graphs to report on your projects. To be honest, once you get the hang of it you wish that MQL provided more functionality so you can generate more metrics straight from MQL. Pretty cool stuff.
• The concept of having a Wiki per card that you can modify is very cool. Once you realize that you also define templates for the Wiki’s for each card, you start to get even more bang for your buck.
• The concepts of Trees and setting up Aggregate properties took a little playing to fully grasp. This might be something that Thoughtworks could generate a FAQ as I’m sure I’m not the only one that had questions. Once you understood the how and why to generate trees and how to create aggregate properties, the benefits of using these structures were unquestioned.
• The ability to create grids or lists from any types of Cards and customize the appearance is awesome. Took a while to grasp just how powerful this is. Once you understand, you can virtually do anything you want.

Pet Peeves

• I really wish I could hide the All, History, and Murmurs tabs. For some projects where we are all co-located, these tabs are not used and they just clutter up the screen.
• I hate how my tabs are in alphabetical sequence (for the most part) and I can’t change the order. Seems like a minor thing, but the experience would be so much better if I could do this.
•  The visualization of the Trees need some attention. This is a great idea for a visualization, but real estate quickly becomes an issue. Options to expand cards horizontally instead of vertically would help greatly. It quickly becomes cumbersome when you have 20+ cards. 

Summary

It will take a bit longer to get the hang of using Mingle as compared to TargetProcess or Rally. But this is time well spent. I will have a real dilemma to choose an Agile Project Management tool for my next project. If you haven’t used Mingle and especially if your project is more flow-based than iteration-based, I’d highly recommend looking into it.

Agile Data Modeling

It has always been a struggle to determine how we can manage our Data Models and Databases in an Agile way. In the past, the Data Modeling tools were limited in the functionality they provided that allowed both collaboration and versioning. Recently the Data Modeling tools have become much better at providing that functionality, but most of the Data Modeling tools I have seen have still provided that collaboration and versioning functionality in a proprietary way that was created by the Data Modeling vendor.

This has made the Data Model and Database operate as second class citizens on Agile projects. Usually separate processes need to be created to determine how we will integrate the Data Model and database into Continuous Integration environments. I believe that some of the resistance of Database Modelers and Database Administrators to implement Agile for Data Design activities is due to the fact that the tools at their disposal have placed them at an Agile disadvantage. Due to this the Data Modelers will prefer the illusion of a more stable Data Model so that they are potentially limiting the number of SQL change scripts they need to generate. (and thereby limiting their technical debt) SQL Change Scripts still seem to be the primary way that people roll out changes to their databases. It is not uncommon for projects to have a huge number of these scripts that then themselves need to be maintained. I have seen a wide variety of ways people use to generate these scripts that vary from a Data Modeling Tool generating them to having a DBA write them from scratch.

Having a large backlog of these scripts and having them be generated in such a way is a huge hinderance to being Agile and accepting change. Having to then try to synchronize these scripts in alignment with check-in versions can be beyond frustrating. And I don’t even want to talk about having to maintain all of these scripts and manually checking them in.

Agile Data Warehouse

For a recent project, we were tasked with creating a Data Warehouse and we needed to create the Data Warehouse in an Agile way. We needed to embrace Agility for two reasons:

1. To deliver the maximum value to the client and deliver the best design that meets actual business needs
2. To address the reality that we will be required to accept changes throughout the duration of the projects as sub-projects are completed

After reviewing Data Modeling tools that I have used in the past, I was still struggling with how we could develop a process that would allow us to easily adopt Agile practices for our Data Models and databases that would allow the Data Warehouse to be run as Agile as other projects.

Oracle SQL Developer Data Modeler

I did some initial investigation of what Data Modeling tools are now available. My objectives were to find an affordable tool that could be used to do the Data Modeling and that all developers could use to view the Data Models and collaborate on them. Most of the tools seemed to fall into two camps:

1. Affordable Data Modeling tools that provided good collaboration but limited Data Modeling and integrated versioning functionality
2. Expensive Data Modeling tools that provided good Data Modeling functionality but limited collaboration and integrated versioning functionality

Then on a list that reviewed the best Data Modeling tools, there was mention of Oracle SQL Developer Data Modeler. It was stated that it was a robust Data Modeling tool that was free. This was certainly something that needed further investigation.

Rarely does a new tool present such functionality that you require time to determine how to use it.

The functionality that was provided with Oracle SQL Developer Data Modeler absolutely changed our project. We now had the ability to be a first class Agile citizen with the rest of the Agile projects and be able to adapt to change easily. We would be able to roll out changes easily and efficiently as new requirements became apparent.

Oracle SQL Developer Data Modeler provided the following functionality:

• Full, integrated functionality with Subversion. The Data Models can be checked in and versioned along with the application code.
• Ability to define a domain library, naming standards, and glossary to ensure a consistent model
• Ability to apply design rules to a model to ensure Data Modeling standards are being followed
• Ability to model Logical, Relational, Dimensional, and Physical Models
• Ability to store DML to populate data along with each table definition. (and determine when they should be executed – at the start/before object creation/after object creation/at the end)
• Use of Barker notation. (Pet Peeve!)
• Extensive functionality to generate different types of models and compare different types of models
• Full versioning functionality to report on the differences between the versions and what changes will be committed on check-in.
• Robust Data Modeling functionality to create Data Models and create physical databases.

Did I mention free so all the developers could use it to reviews the models and make requests? 

Summary

Although we still need to use Database Re-factoring practices to adapt to changes, the versioning and collaboration features of Oracle SQL Developer Data Modeler did cause us to pause and determine how we could best use its functionality. In fact, it caused us to define a process for how we could efficiently roll out Re-factoring changes in an automated way as Oracle SQL Developer Data Modeler now made the Re-factoring manageable.

If you are looking for an Agile Data Modeling tool, I would highly recommend it!

Did I mention it is free?

And the support for the product from Oracle is top-notch. Questions I have had have been answered same-day..

Data Modeling mistake – Violating 4th Normal Form

Looking back in some of the Data Models I have created, I would say they have been pretty good and for the most part modeled the data in the enterprise pretty well. But in a couple of cases, we did create some components of the models that in hindsight leave me somewhat regretful.

The one situation that caused me to reflect was the solution we used to model relationships between three primary entities and addresses. Each of these relationships were a many-to-many relationship so certainly an intermediate table was required. In addition, we also need to define an attribute for the intended purpose of the address. As this was an attribute of the relationship and not the address itself, this was another requirement for a relationship table. So far, so good.

What we eventually decided on was the following structure as an address could be related to an account OR an instruction OR a client.

• contact_method_id (PK)
• Address_id (FK)
• Account_id(FK) – nullable
• Client_id(FK) – nulllable
• Instruction_id(FK) – nullable
• Address fields (no sense listing them all out)

We thought it would be simpler having one table that contained all the relationships to Address. Basically I think we thought that it was simpler from the Data Modeler point of view and made the diagram simpler. But what we underestimated is that it required the developers and business users to understand a more complicated model and know when the different nullable foreign keys would need to be populated. In a sense, we built additional logic into the data model to reduce the number of tables.

4th Normal Form

What we were doing was violating the 4th Normal Form for the reasons of perceived simplicity. In hindsight, I experienced the problems that violating 4th Normal Form can cause.

4th Normal Form is defined as: “Under fourth normal form, a record type should not contain two or more independent multi-valued facts about an entity.”

All my Data Models now are in 4th Normal Form. They may have more entities, but more entities does not mean a more complex model. My standard now is for my Relational models to start in 4th Normal Form and not just 3rd Normal Form.

Now the theory is very important and every physicist needs to know the basics of Mathematics and Algebra before they can apply that knowledge to real world Physics problems. But I find that I am less interested in reviewing the Agile Mathematics and more interested in the Agile Physics. What happens when we introduce friction? How about wind resistance? How about different densities and pressures?

I think that is where Agile gets fascinating. How have different project customized Agile and how did it work? Sometimes people view this customization in a negative way. They say we have bastardized Agile. That we have sullied the Agile principles. I disagree. I believe we are applying Agile Principles to understand and provide solutions to the real world problems when the realities of those problems are encountered. It is much easier to determine how to build a bridge when you don’t have to account for gravity downward and the flow of flood waters against the foundation of the bridge all while taking the distinct soil conditions into account.

I don’t think accounting for those factors sullies the principles of the Mathematics that underpins the design. It just acknowledges that understanding the Mathematical theory is a requirement but not and end-state. How we implement that theory and how it allows us to understand the real world is the real interesting part. In a way, Agile Mathematics and Agile Physics are two separate disciplines.

I wonder if I can get Agile Physicist on my business card?