Disciplined Agile

In Agile Transformation: Being Agile, Doing Agile, and Supporting Agile we described three factors – people (being agile), process (doing agile), and tools (supporting agile) – that in our experience must be addressed during your agile transformation.  In this blog posting we compare agile transformation strategies in terms of addressing combinations of the three factors.  The following diagram overviews the eight potential strategies that you may embark upon.

Let’s compare each agile transformation strategy one at a time:

1. None of the factors are addressed.  Good luck with that.  ??
2. Focus on people only.  When you focus solely on being agile your teams don’t really learn how agile techniques fit together, nor do they understand the implications of how they’re working.  An example of a people only strategy is to give everyone training and coaching in leadership and collaboration skills and then expect them to self-organize into effective agile teams because “they already have the skills and they’re smart people who can figure it out”.  We saw this sort of strategy fail at a large product company when the teams who received this coaching and training invariably went back to their former ways of working.
3. Focus on process only.  With this approach you get “cargo-cult agile” that is layered on top of your existing processes. What we mean by cargo-cult agile is that the team adopts many of the straightforward management practices, the ones that Scrum tends to focus on, such as holding a daily coordination meeting, an iteration/sprint demo, an iteration/sprint retrospective, and iteration/sprint planning.  You end up with people holding “all of the agile meetings” and who on the surface take on their version of agile roles such as Product Owner and Team Lead.  They have the appearance of working an an agile manner but they really aren’t, and worse yet they don’t even know it and usually nor does senior management.  This is a very common problem when an organization’s entire agile transformation strategy is to send their people on two-day workshops so that they may become “certified masters.”
4. Focus on tools only.  Some organizations believe that if they buy several agile tools, or even an entire agile tool suite, and then force their staff to use them that the tools will somehow make their teams agile.  The actual result is that you end up with a “standardized” approach to agile that is both overly complex (the tools typically include far more features than you’ll ever want, many of which provide functionality completely inappropriate for your situation) and incomplete (you can’t automate everything and even if you could the vendors haven’t gotten to it yet).  The worst offenders are the Application Lifecycle Management (ALM) suites, many of which seem to be offered by vendors who themselves are struggling to deliver consumable products into the marketplace.
5. Focus on people and process. A common agile coaching refrain is to address tooling once you understand the process, which is good advice to an extent, but it quickly falls down when you realize that many technical practices such as continuous integration (CI) and automated testing require adoption of tooling from the very start. When you ignore or at least greatly downplay tooling issues you tend to grow “agile purists”, and even “agile zealots”, who only know how to apply agile in simple contexts.  Ignoring tools can ease your agile transformation at first but eventually tends to get you into trouble when you start to apply agile in more complex situations.
6. Focus on process and tools. When you don’t coach people in the skills and mindset around
   “being agile” you tend to end up with cargo-cult agile with automated bureaucracy.  Agile transformation requires a paradigm shift, which inherently implies you need to address what it means to be agile.
7. Focus on tools and people. When you downplay how to “do agile” you tend to get agile children playing with shiny new toys.  They tend to know the agile language and mindset, and will often have a cursory understanding of simple agile practices that they learned on their two-day certified mastery workshop, but they really don’t know how to successfully build consumable solutions from beginning to end.  Teams who receive little help on “doing agile” tend to spend a lot of time, and a lot of money, figuring out the agile process.  Worse yet, they often adopt a WaterScrumFall approach where Inception and Transition tends to be more traditional and heavy and only Construction is lightweight and agile.
8. Focus on people, process, and tools simultaneously.  When your agile transformation strategy addresses all three factors at once you have the potential to create Disciplined Agile teams that can work at scale.  This only happens when your “being agile” efforts help people to shift to an agile mindset, when your “doing agile” efforts teach a comprehensive yet flexible (think goal driven) view of agile strategies and practices, and your “supporting agile” efforts lead to a context-driven, enterprise aware approach to tool selection.

In your agile transformation you will spend much more effort addressing people-oriented (being agile) issues than you will either of process (doing agile) or tooling (supporting agile) issues.  Think of it like this: these three factors are effectively the legs of a stool, if you don’t address all three then your agile transformation will fall over.

If you’d like help with your agile transformation, please contact us via ScottAmbler.com.

Many organizations struggle to transition to a more agile or lean way of working.  In this blog posting we address three questions:

1. What factors should your agile transformation address?
2. How important are these factors in practice?
3. How difficult are these factors to address?

What factors should your agile transformation address?

Our experience is that successful agile transformations need to address three fundamental issues:

1. People (being agile).  This factor addresses issues such as individual mindset, team and organizational culture, and team and organizational structure.  As a Disciplined Agile coach you must help people to evolve to an agile mindset, learn new skills, adopt improved collaboration strategies, and evolve the way they are organized to reflect their new ways of working.  As you can see below, this factor typically comprises between 80 to 85% of your agile transformation effort.
2. Process (doing agile).  As a Disciplined Agile coach you need to help organizations adopt new agile and lean practices, strategies, and the Disciplined Agile (DA) toolkit itself.  This tends to be between 10 to 15% of the overall transformation effort.
3. Tools (supporting agile).   Agile teams will need to adopt new tools, such as continuous integration (CI) tools, testing tools, and perhaps even agile task board software to name a few.  Agilists will use existing tools, such as their configuration management environment, in new ways.  And they will abandon some existing tools, in particular traditional test management tools, that aren’t applicable in the agile world.  Reworking your tooling strategy tends to take about 5 to 10% of your agile transformation efforts.

How important are these factors in practice?

In the 2014 Agile Transformation survey we asked a series of questions around how important it was to address various people, process, and tooling factors.  The survey respondents had either been through an agile transformation or were currently well into one.  The figure below shows that the first and third most important transformation factors were aligned with being agile, the second and fourth most important factors were around doing agile, and the two least important factors were around tooling (supporting agile).

How difficult are these factors to address?

In the 2014 Agile Transformation survey we asked a similar series of questions around how difficult organizations found it to address various people, process, and tooling factors.  The first and third most difficult factors to address were cultural (being agile).  The second and sixth most difficult factors to address were process oriented (doing agile) in nature.  The fourth and fifth most difficult factors addressed tooling.

Our experience is that if you don’t address all three factors in your agile transformation effort that you will run into serious trouble.  This topic will be explored in our next blog posting.

If you’d like help with your agile transformation, please contact us via ScottAmbler.com.

This posting, the latest in a series focused on a disciplined agile approach to data management, overviews the activities that a disciplined agile data management team may perform. The Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy to data management.  DAD does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique.  In this blog we present the goal diagram for the Data Management process blade and overview its process factors.

The following diagram overviews the potential activities associated with disciplined agile data management.

The process factors that you need to consider for data management are:

1. Improve data quality.  There is a range of strategies that you can adopt to ensure data quality.  The agile community has developed concrete quality techniques – in particular database testing, continuous database integration, and database refactoring – that prove more effective than traditional strategies.  Meta data management (MDM) proves to be fragile in practice as the overhead of collecting and maintaining the meta data proves to be far greater than the benefit of doing so.  Extract transform and load (ETL) strategies are commonplace for data warehouse (DW) efforts, but they are in effect band-aids that do nothing to fix data quality problems at the source.
2. Evolve data assets.  There are several categories of data that prove to be true assets over the long term: Test data that is used to support your testing efforts; Reference data, also called lookup data, that describes relatively static entities such as states/provinces, product categories, or lines of business; Master data that is critical to your business, such as customer or supplier data; Meta data, which is data about data. Traditional data management tends to be reasonably good at this, although can be heavy handed at times and may not have the configuration management discipline that is common within the agile community.
3. Ensure data security.  This is a very important aspect of security in general.  The fundamental issue is to ensure that people get access to only the information that they should and that information is not available to people who shouldn’t have it.  Data security must be addressed at both the virtual and physical levels.
4. Specify data structures.  At the enterprise level your models should be high level – lean thinking is that the more complex something is, the less detailed your models should be to describe it.  This is why it is better to have a high-level conceptual model than a detailed enterprise data model (EDM) in most cases.  Detailed models, such as physical data models (PDMs), are often needed for specific legacy data sources by delivery teams.
5. Refactor legacy data sources. Database refactoring is a key technique for safely improving the quality of your production databases.  Where delivery teams will perform the short term work of implementing the refactoring, there is organizational work to be done to communicate the refactoring, monitor usage of deprecated schema, and eventually remove deprecated schema and any scaffolding required to implement the refactoring.
6. Govern data.  Data, and the activities surrounding it, should be governed within your organization.  Data governance is part of your overall IT governance efforts.

Looking at the diagram above, traditional data management professionals may believe that some activities are missing.  These activities may include:

• Enterprise data architecture.  This is addressed by the Enterprise Architecture process blade.  The DA philosophy is to optimize the whole.  When data architecture (or security architecture, or network architecture, or…) is split out from EA it often tends to be locally optimized and as a result does not fit well with the rest of the architectural vision.
• Operational database administration.  This is addressed by the Operations process blade, once again to optimize the operational whole over locally optimizing the “data part.”

Future blog postings in this series will explore the workflow associated with data management.

Related Resources

• The Data Management process blade
• DevOps Strategies: Data Management
• Disciplined Agile DW/BI: Artifact Creation
• Disciplined Agile DW/BI Teams
• The Enterprise Architecture process blade
• Why Data Management?

According to the Data Management Body of Knowledge, data management is “the development, execution and supervision of plans, policies, programs and practices that control, protect, deliver and enhance the value of data and information assets.”  In our opinion this is a very good definition, unfortunately the implementation of data management strategies tends to be challenged in practice due to the traditional, documentation-heavy mindset. This mindset tends to result in onerous, bureaucratic strategies that more often than not struggle to support the goals of your organization.

Having said that, data management is still very important to the success of your organization.  The Disciplined Agile (DA) toolkit promotes a pragmatic, streamlined approach to data management that fits into the rest of your IT processes – we need to optimize the entire workflow, not sub-optimize our data management strategy.  We need to support the overall needs of our organization, producing real value for our stakeholders. Disciplined agile data management does this in an evolutionary and collaborative manner, via concrete data management strategies that provide the right data at the right time to the right people.

There are several reasons why a disciplined agile approach data management is important:

1. Data is the lifeblood of your organization.  Without data, or more accurately information, you quickly find that you cannot run your business. Having said that, data is only one part of the overall picture.  Yes, blood is important but so is your skeleton, your muscles, your organs, and many other body parts.  We need to optimize the whole organizational body, not just the “data blood.”
2. Data is a corporate asset and needs to be treated as such.    Unfortunately the traditional approach to data management has resulted in data with sketchy quality, data that is inconsistent, incomplete, and is often not available in a timely manner.  Traditional strategies are too slow moving and heavy-weight to address the needs of modern, lean enterprises.  To treat data like a real asset we must adopt concrete agile data quality techniques such as database regression testing to discover quality problems and database refactoring to fix them.  We also need to support delivery teams with lightweight agile data models and agile/lean data governance.
3. People deserve to have appropriate access to data in a timely manner. People need access to the right data at the right time to make effective decisions.  The implication is that your organization must be able to provide the data that an individual should have access to in a streamlined and timely manner.
4. Data management must be an enabler of DevOps.  As you can see in the following diagram, Data Management is an important part of our overall Disciplined DevOps strategy. A successful DevOps approach requires you to streamline the entire flow between delivery and operations, and part of that effort is to evolve existing production data sources to support new functionality.

In future blog postings we will explore the goal diagram of the Data Management process blade and the associated workflow.

Related Resources

• DevOps Strategies: Data Management
• DAMA Data Management Body of Knowledge (DMBoK)
• Disciplined Agile DW/BI: Artifact Creation
• Disciplined Agile DW/BI Teams
• The Enterprise Architecture process blade

On February 23, 2016 I gave a webinar entitled How Does Middle Management Fit In An Agile Organization (view the recording).  This blog overviews the webinar and provides answers to the numerous questions that were asked during it.

Webinar Overview

The webinar began with a discussion of four trends that are reducing the need for people in management positions:

1. Technical management tasks are performed by the team. As a result there is much less work for managers to do.
2. Leadership is addressed by new roles. Team leadership responsibilities are in the hands of non-managers.
3. Experienced organizations are moving towards stable teams. Important side effects of this are that much less “resource management” is required and team budgeting is greatly simplified.
4. Status reporting is being automated away. Once again, less work for managers to do.

We then discussed the options that existing managers have in an agile environment. In Disciplined Agile there are four roles that existing managers are likely to transition to: Team Lead, Product Owner, Team Member, and Specialist. Specialist roles – such as Data Manager, Portfolio Manager, Program Manager, and Operations Manager – occur at scale and the corresponding positions are few and far between. Read the article Disciplined Agile Roles at Scale for more details.

We end with words of advice for existing managers: Observe what is actually happening; be flexible; and choose to evolve.

Questions and Answers

We’ve organized the questions into the following topics:

• Evolving to new roles
• Addressing “management activities”
• Potential management roles
• People management
• Management reporting
• During your agile transformation
• Stable teams
• Training and certification

Evolving to New Roles

Will not the existing technical managers be disappointed with only people management work?

That depends on the person. Some will be very happy to do this, some will not.

How will managers fit into a leader role?

It depends on the person again. Some managers are very good leaders right now, some have the potential to be good leaders, and some don’t. They will need training and coaching to fit into their new role(s).

Addressing “Management Activities”

If there are no PMs in Agile, who handles communication with clients (meeting deadlines, priorities, etc.)

The Product Owner. 

How does individual performance to be taken up in Agile team? I think that is more crucial and challenging for Agile Leader / Manager.

It is always difficult to address performance-related activities. There are many lines of thought on how to do this. The most progressive is for the Team Lead to provide feedback to team members on a just-in-time basis. If the Team Lead seems behaviour, either desirable or undesirable, but a team member then they should comment on it right away so as to reinforce or dissuade it as soon as possible. Many organizations still have an annual review process, a strategy that many organizations have abandoned due to it’s ineffectiveness, where functional managers get involved with the review process.

I have seen that you have selected the Team Lead as the responsible of assess team members and budgeting the project. In Scrum the Product Owner is compare to a CEO that’s the reason I would say the Product Owner is responsible for bugdeting and about assessing I prefer a more democratic form which involve all the members. So what do you think about PO managing the budget and a democratic assessing vs one single vision assess?

Yes, I misspoke during the webinar. The Product Owner is often responsible for the team’s budget and is responsible for reporting the current financial information to the stakeholders. The Team Lead is often responsible for similar reporting to their management team.

Having multiple people involved with reviews/feedback is usually a pretty good idea. The People Management process blade captures several potential strategies. However, it is still a good idea for the Team Lead to provide feedback as well, see my earlier answer.

Potential Management Roles

I think there is still a need a bridge manager role between Finance, Teams, and PMO type orgs to ensure Product owners have budget… views. Thoughts?

In smaller organizations this likely isn’t an issue. In larger organizations there is often a Portfolio Management effort that is responsible for such issues.

What might be potential responsibilities of an Operations Manager, Data Manager, …?

Please read the article Disciplined Agile Roles at Scale for descriptions of these roles.

Okay, the data management team needs a team manager/leader. Are large organizations using various resource managers? (Although would be less necessary with stable teams I would think)

Exactly. Large organizations still tend to have people in resource manager roles, although sometimes they have different titles such as CoE Lead or HR Manager, but with stable teams they need far fewer of them.

If the team has a Team Lead/Scrum Master that is only the servant leader for 1-2 teams, is it suitable to have people managers?

What value would a “people manager” bring to the team? This is the fundamental dilemma for managers, for everyone for that matter, when an organization moves to agile ways of working. If they’re not bringing real value to the team then they either need to find ways to do so, which likely isn’t whatever management activities they’re trying to cling to, or they need to go elsewhere and try to add value there.

Do you intend to update the DA 2.0 interative pic on the DAD site to talk about “Potential Management Roles at Scale” as mentioned in page 18 of this presentation?

Yes. We actually have something in beta that we haven’t released yet. We’re just about to release an update to the main picture, which in turn requires an update to the role version of the interactive pic.

What is the most basic difference between Project/Program/Portfolio Managers in Agile?

Quick answer is that there isn’t Project Managers in Disciplined Agile nor in methods such as Scrum, XP, and so on. At the program level (a large team of teams) you likely need someone in a Program Manager (or more accurately Program Coordinator) role to coordinate activities (see the Program Management process blade for details). A Portfolio Manager is focused on the IT level and should be concerned about pre-development activities, development/delivery teams that are currently in flight, as well as operational activities.

Also, please read the article Disciplined Agile Roles at Scale for descriptions of these roles.

People Management

How does one manage the career path of the Team Leads? Is there career progression beyond a TL to be a specialist or does s/he continue being a TL throughout his career?

Everyone is different, so there isn’t one exact answer. It depends on what the person wants to do and what positions are available to them. If their desire is to move into management then there are fewer IT management positions available to them. If they want to become an AO or PO then they need to work towards getting the skills and experience to fulfill those sorts of roles. The People Management process blade includes career management strategies.

How do you evaluate what roles are/will be necessary?

It depends on the needs of the team in the situation that they face. The primary delivery roles typically exist on all delivery teams and the secondary roles start to appear at scale.

How do you see the role of a BA in agile?

Most existing BAs, like most existing project managers, will need to transition to other roles. However, at scale there is a need for some people in the specialist BA role. I recently has a user group presentation recorded on this very topic. See Disciplined Agile Business Analysis: Lessons from the Trenches.

Management Reporting

How do we approach a situation where management wants weekly status reports from a Program Manager who can combine both Team Lead & Product Owner roles, as well as manage multiple projects that may be similar in nature or not.

A few thoughts on this:

1. It’s an incredibly bad idea to combine the TL and PO roles because it puts too much responsibility in the hands of one person. Furthermore, putting it into the hands of a former manager, someone who may have a command-and-control mindset instead of the collaborative mindset required of agile, can exacerbate the problem.
2. You may need someone that Team Leads should work with to coordinate activities between teams (such as a Program Manager or Portfolio Manager) and someone that Product Owners should work with (a Chief Product Owner) to coordinate requirements activities. See The Product Owner Team.
3. I do see stuff like this happen when organizations are transitioning to agile. They are still learning how to make agile work within their environment, they have a lot of people who haven’t yet made the transition, and they have a lot of middle management staff whom they want to treat fairly by finding them other work. Sadly that other work is often overhead that can be done away with given a bit of thinking.
4. If you institute automated dashboards, what we originally referred to as Development Intelligence in Disciplined Agile, then a lot of your status reporting goes away.

In a typical organization, where to team lead(s) report into?

It depends. We’ve seen them report into a Program Manager or a Portfolio Manager. During the transition effort a Project Management Office (PMO) may still exist so Team Leads might report into there, although we often find that there’s a serious cultural and mindset difference that can be very frustrating for everyone involved.

During Your Agile Transformation

What about managers being responsible to support an agile transformation journey in a large organization?

Yes, they would very likely be working as part of an Agile Center of Excellence (CoE), although that would be mostly staffed by experienced agile coaches. There is a need for one or more senior execs to sponsor your agile transformation.

How to deal with “Project Manager” role renamed as “Agile Project Manager” but expected to do the same responsibilities as traditional PM?

We see this sort of stuff all the time unfortunately. First thing to do is to get these people educated in how agile actually works in practice, we’d suggest Disciplined Agile Scrum Master (DASM) or Disciplined Agile Senior Scrum Master (DASSM) as your best option to get the whole picture. Next, work through with them how they would actually add real value on the team (see the discussions earlier). Very likely many of the activities that they think need to be are being handled by someone else or have been automated away. Third, get them some coaching to help them to truly transition to agile.

On my project, I am the Team Lead and there is a Project Manager. So far, I have observed that there are several conflicts in responsibilities. How do we come to an agreement of who handles which responsibilities? For my next project, would you suggest I work on a project with no project manager?

We often have to run facilitated workshops in organizations where we work through the roles and responsibilities that are needed in practice. We do this with a wide range of people and we do so in a collaborative and public manner. You need to come to an agreement as to who does what. Doesn’t sound like that’s happened in your case. When you work through this sort of an exercise you quickly discover that you don’t need a project manager, although there may be some project control officer (PCO) responsibilities that would be assigned to either the team lead or some sort of administrative role (such as PCO).

Do you have any advice on how to deal with the removal of the traditional hierarchy – in a flattening of responsibilities, ‘reporting-lines’ and salaries (or having a vast range of skills and pay-scales all with a job title of ‘team member’?)

This is what an agile transformation will accomplish for your organization. It takes time and investment in your people to implement. I highly suggest that you get some experienced coaches to help you do this.

Management is severely, negatively, personally affected by Agile, and will not look fondly upon it in many cases. Any tips to reduce this? Do you recommend mass management reduction, or multiple smaller rounds?

The first step is to recognize that your organization doesn’t exist to create jobs for managers, regardless of what the managers may think. Agile is about focusing on value, so why wouldn’t a good manager be interested in being actively involved with doing so? My recommendation is always to get training and coaching for everyone, including managers. As I described in the webinar there are many options for existing managers in the agile world if they’re willing to be flexible and evolve. Your organization should choose to help people make these transitions to new roles. However, if people are not willing to make the transition then they shouldn’t be surprised if the find themselves being asked to seek employment elsewhere.

It sounds like the person asking about “who’s responsible for delivery” might have used “responsible” when they meant “accountable” – many managers are the single wringable neck for something in their job description. Do you feel Agile draws the same distinction between the two like ITSM, for instance, does?

Agile is based on a collaborative, teamwork-based mindset. Having said that, it does make sense to have someone ultimately responsible for certain things. For example, the Product Owner is responsible for prioritizing the work on an agile team. Similarly, you may have someone in the Release Manager role who is responsible for overall Release Management within your organization. This is particularly important for regulatory environments where by law you need to have someone not involved with development who makes the final decision as to whether the solution is released or not.

From your observations and experience, what is the average timeframe for the managers number to decrease? How long does the process of the shift take?

It depends. We’ve seen this happen over timeframes as short as six months to several years.  With solid coaching this process will go a lot faster and smoother.

How to motivate and enable senior leaders to give up control?

In agile, particularly in Disciplined Agile, senior leaders have greater visibility and opportunities to steer than what they had in the traditional world. What they need to do is give up their false sense of control that traditional strategies provide. The real issue usually isn’t senior leaders but instead is middle management. They are the people who are currently performing many of the management tasks that are implemented in a more streamlined manner following agile approaches.

How can middle management start the agility journey when top leaders are not yet on board?

Agile typically begins following a stealth adoption strategy where senior leaders are unaware that it’s happening. The point is that anyone, including middle management, can start adopting agile strategies long before senior leadership gets involved. Strategies such as working collaboratively, enabling your team(s) to plan and organize their own work, adopting dashboard technology, and streamlining the bureaucracy whenever possible is very possible to accomplish on your own.

Thanks for being frank about the role(s) for managers in an evolving Agile culture: Agree, traditional project management organization’s aren’t highlighting these trends (and positive outcomes.)

You’re welcome. Traditional project management organizations often go at it from the point of view of how to continue justifying management activities. We go at it from the point of view of how to improve your overall organizational effectiveness and as a result come to a different conclusion.

Stable Teams

Will the idea for stable team become stale after some years? People tend to get frustrated doing same work. What’s the solution in that case?

Stable teams evolve over time. You’ll get people joining the team every so often and similarly leaving the team every so often. It’s natural for people to want to move on and try something new every few years. As a result your organization will still need People Management activities in place that motivate and enable people to manage their careers.

As far as stable teams go, commonly Valve, Inc. is referred to a place where teams are formed around projects that the team members find the most interesting. Project leaders try to sell their project to get developers. Your thoughts?

This is great technique that other organizations may be able to adopt. Allowing teams to form themselves is likely the most effective way to do so. However, like all strategies, there are some potential disadvantages. Team culture may become ingrained and they will not attract people with a different culture who would have the potential to add some real value to the team otherwise.

Is there a method to build the stable teams? Domain, Product, line of business?

There are several strategies for doing this. The most common is to form feature teams that do all of the work to implement a feature as a vertical slice through your entire infrastructure. Another approach is to form component teams that work on a technical or domain component/framework/LoB. A third approach is internal open source. We’ve discussed these strategies in greater detail at Strategies for Organizing Large Agile Teams.

Do you think stable teams concept will work in service-based organisation?

Yes. It’s a bit more difficult because you’d be bringing entire customer projects to the team at once instead of a flow of smaller features. Of course you can break each large project up into smaller features and feed them to teams in an interleaved manner, requiring a sophisticated approach to requirements management.

Training and Certification

What baseline training do you recommend for agile managers?

A good place to start is training on agile thinking, often referred to as how to be agile. Then I would recommend training that describes the full delivery lifecycle from end-to-end, something like Disciplined Agile Scrum Master (DASM) or Disciplined Agile Senior Scrum Master (DASSM). You want to understand all aspects of the agile delivery process, not just the management ones. Scrum training is popular but far too narrow. SAFe training isn’t for beginners.

I would like to participate in a certification workshop/further training. There doesn’t seem to be many offerings in the US. Are there plans to expand training opportunities in the states?

Yes. In fact we have training coming up in the Baltimore area in March and Philadelphia in April. We will have more open enrollment workshops scheduled soon.  Please visit the homepage of Disciplined Agile for a listing of upcoming public workshops.

What should we be telling folks that have PMP’s – are they still valid? is PMP training moving toward Agile software development.

Yes, the PMI is moving towards agile but they have a very large ship to turn. Unfortunately the PMI training tends to suffer from the challenges that I described earlier – it seems to promote a rather unrealistic vision of how managers can potentially fit into agile.