At the Agile 2019 conference in DC I facilitated a workshop with about 70 people where we explored the topic of how do you coach an agile data warehousing (DW)/business intelligence (BI) team. To do this we worked through four issues:
What challenges do you face?
What skills/knowledge does an agile DW/BI coach require?
What strategies should you apply to engage with a DW/BI team?
What are the qualities you should look for in an agile DW/BI coach?
The basic strategy was to introduce the issues to the class one at a time, then at their tables they would discuss the issue and write up to five ideas on sticky notes, then we’d share the ideas. Pictures of the flipcharts for each issue follow below. After the groups shared their ideas I then shared my thoughts with the class.
Issue #1: What Challenges Do You Face Coaching DW/BI Teams?
As you can see the class identified a lot of the classic issues that agile coaches face in general, such as trust issues, the teams being management-driven instead of self organizing, lack of agile skills within the team, cross-team dependencies, and being overwhelmed with work. Certainly there were DW/BI flavours of common problems, such as how to do vertical slices of DW/BI functionality and which lifecycle (agile, lean, CD, …) to follow. But there were also DW/BI specific issues, such as lack of access to data sources, knowing the actual data, and DW/BI architecture and design strategies. These DW/BI specific issues are where agile coaches tend to get hung up.
Challenges commonly faced when coaching agile DW/BI teams (click to enlarge).
In my discussion of the challenges that we face when coaching agile DW/BI teams I shared my thoughts on the cultural impedance mismatch that exists between the agile and data communities. This mismatch makes it a bit more difficult to engage with data teams as opposed to application development teams. I also shared results of studies (2009, 2013,2016, 2018) around data quality challenges and practices – it is certainly common for teams to have to deal with technical debt, but data technical debt is both different in nature than code quality debt and the traditional data culture has led them down a very questionable (read dysfunctional) path regarding quality practices.
Issue #2: What Skills/Knowledge Does an Agile DW/BI Coach Require?
The second issue that we explored was what skills/knowledge does an agile DW/BI coach need. Once again the groups identified both classic agile coaching ideas as well as DW/BI specific ideas. Clearly you need coaching skills in order to coach a DW/BI team. But you also need to be knowledgeable about critical skills such as data modeling, data analysis, database testing, database refactoring, and others. You might not be an expert at these things, but you need to know of them and be able to guide the team in their adoption. You’ll also need to be able to speak intelligently about why some of the traditional strategies that they likely hold near and dear to their hearts (remember the cultural impedance mismatch) need to be abandoned for better, more effective strategies.
Skills/knowledge required of an agile DW/BI coach (click to enlarge).
In my discussion I overviewed the “agile database techniques stack,” a collection of agile strategies and practices for database development. The stack is:
As you can see, this list of techniques is fairly common from an agile point of view, albeit the corresponding data(base) versions of those techniques. The point is that the techniques exist that enable data professionals to work in an agile, and far more effective, manner. As a coach you will need to be aware of these strategies and be able to help your DW/BI team adopt them. And of course there are agile data management strategies that you need to be aware of as well.
Issue #3: What Strategies Should You Use To Engage Successfully With An Agile DW/BI Team?
The groups identified a collection of great strategies for engaging with DW/BI teams. Once again there were a lot of standard coaching strategies, a DW/BI team is still a group of people after all, but there was also a focus on strategies to address the DW/BI challenges identified earlier.
Strategies to engage successfully with a DW/BI team (click to enlarge).
The discussion that followed the sharing of the stickies a very interesting point was brought up. I had earlier stated that my experience with coaching DW/BI teams was that it was different than coaching other types of teams, mostly because of the cultural impedance mismatch. A handful of agile DW/BI coaches in the audience disagreed with that, pointing out that the critical issue was gaining the trust and respect of the team at the start. This is true of any team, and certainly true of DW/BI teams. To do this you need to understand and appreciate the issues that they deal with and be able to show that you know how to guide them through addressing their issues. You might not be an expert in the techniques of the agile database technique stack, or other important agile data techniques, but you do know of them and can help the team learn them. So yes, engaging with an agile DW/BI team is no different on the surface, but it does require the coach to have different skills and knowledge than what your typical agile coach has.
Issues #4: What Are The Qualities You Should Look For In An Agile DW/BI Coach?
For this exercise I pretty much asked the groups to put together a list of qualities for a job ad for an Agile DW/BI coach. This is what they came up with.
Potential qualities of an agile DW/BI coach (click to enlarge).
Our Learnings
Here are our main learnings regarding coaching an agile DW/BI team:
To effectively engage with a DW/BI team, you need to gain their trust and respect – to do that you need to show that you understand the challenges that they face and can help them to address them
To do so can be more challenging than with an application team due to the cultural impedance mismatch, the nature of data-oriented technical debt, and the lack of modern development skills within the data community – all of these challenges point to a greater than normal need for coaching on such teams
In my experience in running dozens of process tailoring workshops, over several years, with of teams of every shape size and experience level and in different organizations, the most recurring comment is that the workshops “revealed all kinds of options we didn’t even realize were options!” Although almost always a bit of a hard sell at the outset, I have yet to work with a team unable to quickly grasp and appreciate the value of these activities.
I had to do quite a bit of experimenting in order to get the timing and content of the workshops right – and learned over time that success is also predicated on knowing whom to include when. My first attempts were gruelling, close-to-full day affairs with entire teams in attendance, held at or close to project kickoff. Though transparent and inclusive, to my surprise this approach was actually deemed a waste of their time by many team members, especially those whose contribution would occur primarily in the construction phase. First lessonlearned – A technical team lead, architect or senior developer can actually stand in for most of the developers in the early stages. I find it helpful to always bear in mind what George Dinwiddie (http://www.velocitypartners.net/blog/2014/02/11/the-3-amigos-in-agile-teams/) dubbed “the 3 amigos” in determining who needs to attend a process tailoring session. Be it at inception, construction, or even in transition, you need to tailor not only the processes, but also the attendance of the workshop in order to ensure you have the right mix of people, with the right collaborative mindset, to cover issues pertaining to 1) the business problem being addressed 2) the potential technical solutions to that business problem and 3) the processes (both team and organizational) that will enable the work to be carried out.
My second lesson learned pertained to the format and presentation of the process blades themselves. I found that simply working from the published process maps was insufficient, as we ran into onerous issues around how to best record the WoW choices teams were making. I eventually reproduced the entire process blade library in a spreadsheet format, with columns for comments. This seemingly innocuous administrative step quickly ushered in the third lesson learned – the sessions can be used not merely to document an immediate WoW decision, but also to identify future, more “mature” aspirational choices which the team can set as goals over a specified time period.
A fourth lesson learned, and one that was also enabled by using a simple spreadsheet tool, is that it became far easier to Align with Enterprise Direction. By “locking down” enterprise-level process choices across all the blades where applicable, a lot of potentially fruitless (at that point in time) discussion was saved for many a team. No use in discussing test automation strategies to death for instance in divisions still completely relying on manual tests, or at the opposite end of the spectrum, teams endowed with high-performing, well-integrated CI/CD environments. This is a large part of what DA calls self-organization within appropriate governance.
The fifth and final major lesson learned was to never start from a blank slate if at all possible. I would typically show up at a team’s first process tailoring workshop with a pre-filled version from another team facing somewhat similar challenges (the identifying data being scrubbed so they could not identify the previous team). I would then challenge the new team to reflect on the choices and determine whether they made sense for their own context. This also saved time and effort, as there are recurring themes and common challenges within organizations that all teams face.
Here’s an important note on determining participation – Ultimately, the teams themselves are the best arbiters of who should attend the sessions at varying stages of advancement. Allowing this will typically result in a bit of initial over participation, followed by under participation (especially is the pressure is on to get “real” work done!) – the key as facilitator is to coax the team back into balanced participation, and to lobby the organization for the necessary support in freeing people up. The support will become easier and easier to obtain as the benefits of allowing teams to choose their WoW become apparent.
Finally, be prepared for surprises. I once ran through the Program process blade with a team, only to have them come to the realization that … they weren’t really a Program! Which was actually a good thing as it helped avoid introducing a considerable amount of overhead, particularly in the area of program-level KPIs.
I recently ran into The Oath for an Agile Coach. There are clearly some great ideas in the oath and it would be hard to argue that you wouldn’t want to adopt the advice contained within it. So I won’t do that. However, I do feel that there are some serious challenges surrounding the oath but that with a bit of hard work we could do better.
Some Great Ideas Here
Frankly, what’s not to like? The oath promotes the idea that coaches should do no harm, that they’re guests, that they should respect learnings, that they value discretion, and many other wonderful philosophies. Several of them are arguably a bit naive, for example:
First, do no harm. From one point of view the definition of an agile coach is to do harm – harm to the status quo, harm to the incumbent mindset, harm to the corporate politicians who rose to power building the current environment that the coach is there to help the organization improve. You wouldn’t be much of a coach if you weren’t doing harm to the bad stuff in your organization.
I prevent dysfunction. Really? I’ve worked in many environments that are “target rich” when it comes to dysfunction. I’m expected to help prevent all of these dysfunctions right away? I’m supposed to prevent dysfunction that is beyond my current scope of influence? Of course not. I need to help the people that I’m working with to identify and prioritize their pains, then help them address these pains as and when it is appropriate to do so (if ever). Clearly the advice in the oath is context sensitive and it isn’t meant to be taken literally.
It’s clear to me that a lot of smart people have put a lot of effort into the oath, that they’ve thought it through, and are honestly trying to make things better. I also believe that this is a step in the right direction, although at the time of this writing there are some serious challenges surrounding it that can and should be addressed.
A Few Serious Challenges
First and foremost, we should give the authors of the oath the benefit of the doubt and assume that they aren’t doing the things I’m about to describe on purpose. Although what I have to say is harsh, I honestly believe that the authors have their hearts in the right place but have not thought through the implications of what they’ve started. So here goes.
The oath is deceptive and as a result possibly unethical. The reason why I say this is that they claim to have based the coach’s oath on the The Hippocratic Oath (which I’m sure they’ve actually done). The problem is that they’ve merely skimmed the surface of the Hippocratic Oath, lifting ideas such as “First, do no harm” (which the oath doesn’t actually say, that’s the Hollywood interpretation of it) without also adopting the context in which the Hippocratic Oath is taken. This is important. New medical practitioners, after years of training, are asked to take the oath, or something similar, by medical schools. These schools are governed and the medical professionals themselves are governed. Control mechanisms are in place to ensure that the people who take the oath know what they’re doing and work in a trustworthy manner. Therein lies the rub – no such governance exists for agile coaching and I suspect the vast majority of agile coaches would chaff at the suggestion.
To see why this is an issue consider the following example. I have no medical training or background, with the exception of taking a few first aid courses over the years. Come to think of it, by agile standards I have more than enough medical training to be considered a Certified Surgery Master (CSM), so it’s all good. I have just now recited the Hippocratic Oath and have pledged to abide by it. As a result I now feel that I am qualified to offer plastic surgery procedures as I’ve heard that this is a lucrative business to be in. If you would like a face lift, liposuction, or augmentation of a body part please contact me to arrange a procedure. You can trust me because I’ve recited the Hippocratic Oath and I’m a CSM. What? You’re not interested? I’ve pledged to do no harm, so you can trust me.
I think that you inherently know it would be a bad thing for me to perform plastic surgery on you. I’m obviously not qualified. Therein lies the rub. I could easily advertise that I’ve pledged the oath, tell people about my CSM credentials, and make it sound like I’m qualified, particularly to people who don’t have much of a background in agile. In fact, recently in Toronto, a 19-year old woman did something very similar to this and as you’d expect it didn’t work out well for the recipients of her surgery endeavours.
By claiming that the agile coach’s oath is based on the Hippocratic Oath the authors are taking advantage of something called “prestige association.” The Hippocratic Oath is prestigious – the people who pledge it have to work very hard to be asked to pledge it and are subsequently held to its high standards throughout their careers. By explicitly associating the agile coaching oath with the Hippocratic Oath the prestige of the latter is conferred to the former. This is deceptive at best and unethical at worst. I believe we can be better than this.
How We Can Do Better
It isn’t appropriate to complain about the Agile Coach’s Oath without also providing some possible ways to fix it. Here are my initial thoughts:
Avoid prestige association. The very first thing, and easiest thing, that could be done is to stop comparing this oath to the Hippocratic Oath.
Define paths to becoming a great coach. A straightforward, and relatively easy, way to add real value would be to put together a path, or more likely several paths, that people could follow to become a great coach.
Help people to follow those paths. In short, build a respectable agile coaching guild that focuses on helping people over making money off of them.
We need to respect ourselves. This is an observation for agilists in general, but particularly important for agile coaches. At the present moment the Agile Coach’s Oath is yet another vapid agile band wagon for people to jump onto without having to do any real work. As coaches we lament the large number of lame agile “certifications” that are little more than participation ribbons, so perhaps it’s time we choose to say enough is enough. We know that effective coaching requires skill, knowledge, and experience that require years of hard effort to earn. Just like the medical community requires years of education and training before extending the privilege of asking someone to take the Hippocratic Oath, we could choose to do something similar. But first we’d need to respect ourselves enough to actually do that.
I believe the people who developed The Oath for an Agile Coach have good intentions. They’ve gotten a great start on an interesting and potentially valuable idea. But, they need to follow through and make it something real if they really want this oath to be meaningful. I hope they choose to build a vibrant community that does exactly that. Time will tell.
When your organization chooses to transition to more agile and lean ways of working you quickly discover that this effort needs to address all aspects of your organization, not just your solution delivery teams. Many transformation efforts invest in agile team coaches, which is a very good thing to do, but will often shortchange other areas of coaching in the belief that they’ll figure it out on their own. It may work out that way, but even when it does this is an expensive, slow, and error-prone approach. In our experience it’s far better to get help from an experienced Enterprise Coach.
An Enterprise Coach coaches “beyond the team” to help senior managers and leaders to understand and adopt an agile and lean mindset. As you will soon see, this requires a similar yet different skill set than what is required for team coaching. In this blog we work through three key concepts:
As you see in the following diagram we like to distinguish between several types of coaches:
Team coach. As the name suggests, a Team Coach coaches solution delivery teams through improvement efforts. The focus is usually on improving the performance of individual teams. This is the most common type of coach, and our guess is that 95% or more of agile coaches fall into this category.
Specialized coach. A “specialized coach” is someone who focuses on non-solution delivery aspects of your organization. They are typically senior team coaches who have a deep background in one or more process blades. For example, you may have a specialized coach focused on Enterprise Architecture and Reuse Engineering for example; or one that is focused on Finance, Portfolio Management, and Control; or one that is focused on Enterprise Architecture and Data Management. The people who are working in non-solution delivery areas need coaching just like people on solution delivery teams do. More on this in a future blog posting.
Enterprise coach. Sometimes called Transformation Coaches or Executive Coaches, these coaches work with senior and executive management to help them to understand new ways of working and organizing themselves. Enterprise coaches will often focus on executive coaching, of which there are three types: IT executive coaching, business executive coaching and manager coaching. All are equally vital to your agile transformation and continuous improvement efforts. An area often ignored in coaching is the role of managers as agile leaders and coaches of your agile teams. Executive Coaches can help guide managers from a style of “managing” to leadership. Enterprise Coaches often find that they also need to take on the role of a Specialized Coach too. A key responsibility of an Enterprise Coach is to support the other coaches when they need help. The focus of this blog is on Enterprise Coaches.
Skills of An Enterprise Coach
The skills of an Enterprise Coach include:
Coaching skills. First and foremost, enterprise coaches are coaches. They require all the people, collaboration, and mentoring skills of other agile coaches. They should have many years of hands-on coaching of individual agile and lean teams in many types of situations, from the simple to very complex.
Domain knowledge. An enterprise coach must have knowledge of the domain that they are working in. There are unique challenges in financial organizations that you don’t see in automotive companies, similarly pharmaceutical companies are different from retailers, and so on. Yes, it is possible for Enterprise Coaches to quickly learn the fundamentals of a new domain, but you’ll find that in the beginning the executives that the Enterprise Coach is helping to learn agile will have to help them learn how the business runs.
Understanding of how IT works. Enterprise Coaches need to understand how a Disciplined Agile IT (DAIT) department works so that they can coach IT executives effectively. Enterprise Coaches help IT groups such as Enterprise Architecture or PMOs to understand how they need to adapt to effectively support Agile teams.
Understanding of how to apply agility at the enterprise level. Similarly, Enterprise Coaches should understand how a Disciplined Agile Enterprise (DAE) works. Enterprise Coaches should be experiences with modern agile practices related to non-IT functions such as human resources (also called People Management or People Operations), finance, and control. Coaches bring expertise on practices in these areas such as modern compensation and reward systems, agile budgeting, rolling wave planning, agile procurement, and agile marketing.
Experience and knowledge of the various IT domains. A broad understanding of IT is critical, and better yet deep knowledge of several of the IT process blades so that someone in the Enterprise Coach role can guide any specialized coaches or step into that role themselves. This is important because people working in areas such as Data Management, Release Management, or IT Governance often believe that they are “special” and agile can’t possibly apply to them (it’s only for programmers after all). Without a good understanding of these areas an Enterprise Coach will struggle to help the IT leaders that they are coaching to counteract these arguments.
Transformation and improvement coaching. Enterprise Coaches should understand, and be experienced at, lean approaches to organizational transformation and improvement, often referred to as Organizational Change Management (OCM). Traditional approaches to OCM will not work.
Ability to support team and specialized coaches. See below.
Supporting Other Coaches
Enterprise Coaches support other coaches in several important ways:
Transformation/improvement visioning. Enterprise Coaches help executives to understand modern agile and lean practices used by successful agile organziations and help to create a roadmap for moving from their current to target state.
Organizational structural change. Experienced coaches can help organizations to create organizational structure to be conducive to the evolution of high performance teams. This would include design of cross-functional, stable teams aligned to value streams or lines of business (LOBs). They can also help design workspaces for effective collaboration between team members, and help reduce the need for separate meeting rooms.
Organizational coordination. One of the most important things that an Enterprise Coach does is help team coaches to overcome challenges collaborating with other, not-so-agile teams. The reality is that 96% of agile teams must collaborate with one or more teams or groups within their organization at some point, 96%! Some of those teams may very well be struggling with working in an agile manner and may even be opposed to it. These sorts of challenges are often beyond the remit of a team coach to address, so when they occur the team coach will often ask for help from an Enterprise Coach who does have the relationships with the right people to smooth over such problems. Enterprise Coaches can also provide advice for effective collaboration strategies with vendors and offshore teams.
Resources. Enterprise Coaches will sometimes help other coaches to obtain the resources – typically time and money – required to coach the teams that they’re working with.
Communication. The Enterprise Coach will actively share the overall vision of your improvement efforts, the current status, and any organizational challenges that you’re running into with the other members of the CoE. They will of course be actively working with the people responsible for communicating this information to the rest of the organization as well.
Coordination. Enterprise Coaches will often coordinate the efforts of the various team coaches in your organization to ensure that they’re working together effectively.
Mentoring. Enterprise Coaches, being senior, will often be coaching the team and specialist coaches (all the while learning themselves).
There is of course a lot more to agile coaching that what is covered in this short blog. Our goal with this writing was to overview the role of Enterprise Coach and show how it fits into the overall scheme of things.
A common question that people ask is how does the adoption of agile within a team affect its productivity? The answer to this question will vary by team, but there are several common patterns that we’ve seen over time. In this blog we explore:
Productivity is defines various measures of the efficiency of production, and is calculated as
Value of Output divided by Cost of Input
The implication of this calculation is that there is flexibility in the way that we can increase the productivity of a team:
Produce the same output with less cost (i.e. with fewer people).
Create greater value with the same number of people.
Deliver value incrementally more often, thereby earning value sooner for a longer period of time (this is called decreasing the cost of delay)
Remember that context counts – each team will choose the most appropriate way for them to increase their productivity. Having said that, a common result of a team adopting agile is to incrementally deliver value more often.
Agile Adoption Patterns
The following diagram overviews three common patterns when it comes to productivity change when teams adopt agile. You’ve likely seen simpler versions of this diagram elsewhere that only show the dark green line, but our experience is that’s only part of the story. You can see in all three cases that the adoption of agile results in an initial productivity loss on a team – this reflects the reality that with any type of change it will take time for a team to learn the new strategy, to identify how it fits into their environment, and to learn the new requisite skills and behaviours.
The three patterns, from least desirable to most desirable, are:
A failed agile adoption (red line). Teams fail to adopt agile for several reasons, usually because the team doesn’t want to adopt agile ways of working, the organization doesn’t properly support their adoption efforts, or the rest of the organization continues to drag them down with traditional ways of working.
A successful agile adoption (green line). Luckily most teams succeed in their agile adoption efforts, and numerous studies have shown a wide range of benefits including faster time to delivery, increased quality, increased stakeholder satisfaction with the delivered solution, and improve team morale to name a few. Every team is different, but overall on average adopting agile is a positive experience. You’ll land on this curve when you treat agile adoption as a project, something you do for a few months to help make the team more effective, if you’re successful.
A successful agile adoption evolving into continuous improvement (green dashed line). The most successful teams realize that process improvement isn’t a short-term project but instead is a long-term journey that you undertake. This is reflected in the dashed line in the diagram below. You typically start by following a transformation strategy with the team – you get them some initial training, some coaching, help them change their work environment and tooling to be more collaborative. Then at some point an improvement mindset begins to take hold within the team, one of the fundamental aspects of agility. The team reflects on a regular basis, identifying potential ways that they can improve and then they experiment with those strategies to see which ones work in practice for them. It’s at this point that they’ve shifted out of the transformation strategy into more of a continuous improvement strategy, which is what enables them to reach higher levels of productivity than what is typically achieved with just a transformation strategy.
What Are the Key Milestones to Look For?
There are three key milestone points on the successful paths that you should watch out for:
Productivity trough (4-8 weeks). With anything new there is always a learning curve, and agile is no exception. When a team begins to move towards agile their productivity will drop for several reasons: they will likely invest some time taking training, it will take people time to learn new techniques and adopt new ways of working, and it will take time for the team to determine how they will work together following these new agile strategies. Your productivity levels tend to bottom out after four to eight weeks and then after that will start to improve. The amount of time varies by team, depending on whether any team members have previous agile experience that they can leverage, how much team members want to change, how effective the training is, and whether you have the support of an experienced and effective coach.
Productivity recovers (2-4 months). For most teams, the ones who are successful at becoming agile, their productivity levels will recover back to the level they were before they started on their agile improvement journey, within two to four months of starting. This amount of time depends on the same issues mentioned before.
Improvement culture takes hold (3-6 months). This is the point where the improvement mindset really kicks in and the team starts to explicitly work together to improve the way that they work. This is a reflection that the team is actually “being agile” and not just doing agile ceremonies. Sadly not all teams reach this point and move up onto the dashed green line in the diagram above. Whether they do so or not is primarily dependent on the willingness of team members to become agile, the quality of the coaching that they receive, and whether your organizational environment allows them to own their process.
How Can You Improve Your Chance of Success?
There are several strategies that you can employ to increase your chance of successfully adopting agile and shifting to a continuous improvement culture within your team:
Invest in training. Get the team started on the right foot with training that not only goes into the fundamental concepts behind agile (“being agile” training) but also works through from beginning to end how agile works in practice (“doing agile” training). Being agile training is incredibly easy to find, but good “doing agile” training that is comprehensive is much harder to find. Luckily there are several very good Disciplined Agile training offerings that focus on how to “do agile” in enterprise-class settings.
Hire an experienced coach. A good coach will help your team to avoid common learning pitfalls, and better yet quickly guide you through “learning experiences”, working through with you how to improve the way the team works. Hiring a coach can be a challenge because as we show in Why is it so hard to find qualified coaches? it is possible for anyone, and unfortunately they often do, to claim that they are an agile coach. Effective coaches have deep experience in what they are coaching as well as skills in the act of coaching itself. The majority of “agile coaches” tend to to be short on both of these things, and the few coaches that are qualified are in high demand. There are several Certified Disciplined Agile Partners that you may want to reach out to for Certified Disciplined Agile Coaches (CDACs).
Give the team an “organizational pass.” It’s incredibly difficult for a team to become agile when they are still surrounded by other groups that are actively working in a non-agile manner. Agile teams need to collaborate with others to achieve their goals (in fact, the 2016 Agility at Scale study found that 96% of people indicated that their team needs to interact with at least one other team). So, if you want to enable a team to become more agile and improve then you also need to motivate these other teams they rely on – such as the data team, the enterprise architects, and even the governance team – to be sufficiently flexible to work with the agile team in an agile manner. In some cases the agile team may need to be “given a pass” from creating the mandated artifacts, or having to jump through the mandated “quality gates”, required by these teams.
Help the teams that they collaborate with to become more agile. The next step after giving an agile team an organizational pass it to recognize that this is an opportunity to experiment with improving other areas within your organization. Help the enterprise architects to learn about agile and to try a few agile strategies themselves. Similarly the data team can experiment with agile data management strategies and certainly your IT governance team can also take the opportunity to up their game as well.
How Do You Know That Your Productivity Actually Improved?
Although the chart above intuitively makes sense, how do you know that your productivity has actually increased? To definitively answer this question you need to determine what productivity means to you, what the productivity level of the team currently is, and then continue to measure the level of productivity over time. This strategy tends to fall apart because few organizations know how they want to measure team productivity and fewer yet have actual measures in place. This of course is particularly vexing when senior management still requires you to prove that your productivity has increased as the result of your agile adoption efforts. Luckily there are ways to measure the change in productivity even when you don’t know what the baseline productivity level currently is. We’ll address this topic in a future blog.
Agile is About More Than Productivity Improvement
There are many benefits to agile, improving team productivity being just one of them. Potential benefits, some of which lead to greater productivity, include:
