.png)
Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
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:
In future blog postings we will explore the goal diagram of the Data Management process blade and the associated workflow. Related Resources |
(In Agile) Where do all the managers go?
Categories:
agile,
People,
Scrum,
Portfolio Management,
Product Management,
Project Management,
Program Management
Categories: agile, People, Scrum, Portfolio Management, Product Management, Project Management, Program Management
| 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 OverviewThe webinar began with a discussion of four trends that are reducing the need for people in management positions:
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 AnswersWe’ve organized the questions into the following topics:
Evolving to New RolesWill 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 RolesI 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 ManagementHow 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 ReportingHow 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:
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 TransformationWhat 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 TeamsWill 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 CertificationWhat 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. |
Combining Agile and CMMI? Then You Better Be Disciplined
|
One of the great advantages of agile and lean software development is the wealth of practices, techniques and strategies available to you. This is also one of its greatest challenges because without something like the DA toolkit it’s difficult to know what to choose and how to fit them together. The DA toolkit adopts practices and strategies from existing sources and provides advice for when and how to apply them together. In one sense, methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DA the mortar to fit the bricks together effectively. Another strategy to process improvement is captured by the Capability Maturity Model Integrated (CMMI)-Development (CMMI-Dev) approach. With this strategy organizations will organize their improvement efforts around the CMMI process areas, which has the effect of local optimization of each process area at the expense of the overall flow and efficiency within your software process. The fact that CMMI-Level 5, which few organizations achieve in practice, focuses on process optimization belies this point that overall flow tends to be an afterthought in CMMI environments. It is possible to combine agile and CMMI approaches together, as a quick Internet search will reveal. There appears to be a fair bit of evidence showing that applying agile within CMMI environments appears to improve the situation. It is our opinion that applying CMMI to agile teams tends to decrease their effectiveness in practice. A better strategy is to first apply the DA toolkit with the goal of streamlining your overall software process. Then if, and only if, you need to be CMMI-compliant you should make changes to your process to become compliant. As we show in Mapping CMMI-Dev to Disciplined Agile the DA toolkit can be fully CMMI-compliant. The DA framework in effect shows how to weave the various process areas together. For example, the Produce a Potentially Consumable Solution process goal includes process factors such as Needs Exploration, Solution Exploration, and Planning which map to aspects of Requirements Development (RD), Technical Solution (TS), and Integrated Project Management (IPM) CMMI process areas respectively. By starting with DA, you will tailor a light-weight software process to meet your actual needs while only requiring a few (hopefully) minor tweaks so that you can easily pass a SCAMPI assessment. In short, get the process right and then make it CMMI compliant – focusing on CMMI-compliancy will almost assuredly guarantee you have a software process that is heavier than it needs to be. Via the combination of supporting multiple lifecycles and lightweight process tailoring via application of process goals the DA toolkit provides a context-sensitive and scalable approach to the agile software process. Furthermore, the DA toolkit presents time-oriented advice, e.g. at this point in time here’s what you need to do and here’s how it fits together, that is actionable by agile teams. In short, the toolkit takes the mystery out of how all of these agile and lean techniques work together in practice. Our fundamental advice is to avoid CMMI if at all possible. If you then your best bet is to take a Disciplined Agile approach to CMMI compliancy.
|
Recovery Testing
|
by Danial Schwartz In Disciplined Agile Delivery (DAD), testing is so important we do it all the way through the lifecycle. One approach that your team will need to consider performing is recovery testing, which is used to see the ability of a system to handle faults. If a fault occurs, does the system keep working and does not stop? In case of a fault can the system recover within a specified period of time? In the event of a critical failure will damage such as physical, economical, health related, etc., result or not? Recovery testing constitutes of making the system fail; then the results of system recovery are observed. The efficiency of the system to return to normal and the time it takes to do so are examined. The disturbances which can result in failure and need to be checked vary from product to product and from industry to industry. Consider the healthcare industry and medical devices. When products are developed for the health care industry they have to be in strict accordance with FDA guidelines. They also have to adhere to the guidelines provided by the company for which the product is being made. When recovery tests are made they naturally have to comply with these strict rules. The tests require validation and so does the environment in which they are to be carried out. The Defense Industry consists of complex systems embedded within one another. The interlink of the systems requires recovery testing which takes into account how different systems affect one another. Since the industry has to deal with harsh environmental variables, these have to be replicated for recovery testing. Doing so is no easy task. Cloud applications are increasing in popularity. They are part of cloud systems. The cloud systems, in turn, are made up of commodity machines. This allows taking advantage of economies of scale. But this results in needing to use complex software which makes recovery testing quite a challenge. Before a recovery test can be carried out, the software recovery tester has to make sure that recovery analysis has been undertaken. A fail over test is designed. The fail over test serves to determine that if a given threshold is reached, can the system allocate extra resources. It also serves to show if, in case of critical failure, a system can distribute resources and continue to operate or recover within a specified time. Consider the example of a server which is reachable but it is not responding as one would expect it to. This is the fail-over cause. The result of this, known as the possible impact, could be a crash. The severity of the impact is medium to high. To simulate this one could initiate wrong responses on the server side. Another example of a fail-over cause is a power supply failure. If the failure was in the auxiliary power source its possible impact could be a complete shutdown. This is critical. To simulate this the system could be subjected to a change in power strength or the power cord could simply be unplugged. A low impact severity example includes a DB overload. This could result in slow response time. It could also result in information not being fetched from the DB leading to an error. Using appropriate tools a load test could be created to simulate this scenario. At times a service might stop posing a low to high impact severity depending on the service which stopped. There might not be any possible impact or an application might stop working. To simulate this one could stop the service manually to see the possible impact. The tester also has to ensure that the test plan and test environment are prepared, information is backed up, the recovery panel has been provided education and a record is kept of the techniques used for recovery. Use of resources and having to deal with unpredictable possibilities makes recovery testing a daunting task, but its benefits are worth the trouble. First, recovery testing improves the system quality. It removes risk since one knows that in case of a failure the system will continue to work. Second, recovery testing results in a staff which is educated to perform recovery failure when need arise. Third, recovery testing also fixes problems and mistakes in a system before it has to go live. Finally, recovery testing shows how important recovery is and raises awareness of the fact that long term business continuity relies heavily on recovery management. In conclusion, recovery testing is used to see how a system behaves when failure occurs. Recovery testing can be a tedious process but shows the efficiency of a recovery plan, educates the staff on how to deal with faults and failures which occur in systems, highlights the importance of recovery at times of crisis to members of the IT and business organizations, and shows how important it is to the long term success of a business to have a recovery strategy in case of a disaster.
About the AuthorDanial Schwartz is a content strategist who sheds light on various engaging and informative topics related to the health IT and Q&A industry. His belief in technology, compliance and cost reduction have opened new horizons for people in the health care industry. He is passionate about topics such as Affordable Care Act, EHR,testing, test automation, and privacy and security of data.
Related Resources |
Why should organizations be interested in Disciplined Agile certification?
|
Disciplined Agile certification is for agile professionals working in enterprise-class settings such as banks, insurance companies, retailers, and government agencies. You’re not working in ideal situations – you have legacy cultures, legacy systems, and legacy processes to overcome – but that doesn’t mean you can’t make things better. You take pride in your work and you want to create environments where you can be effective, and you can do that by adopting Disciplined Agile strategies. For organizations the primary value of disciplined agile certifications are that they indicate that people have gained a certain level of knowledge and in some cases expertise in Disciplined Agile methods. Our principled approach to Disciplined Agile certification results in respected certifications that you can trust. There are several benefits of Disciplined Agile certification for organizations:
The Disciplined Agile Certification ProgramThe Disciplined Agile Certification program has three main certifications for practitioners – Certified Disciplined Agilist (CDA), Certified Disciplined Agile Practitioner (CDAP), and Certified Disciplined Agile Coach (CDAC) – that build upon each other. There is an additional designation, Disciplined Agilist (DA) and a fifth designation for trainers, Certified Disciplined Agile Instructor (CDAI). Certified Disciplined Agilist (CDA): Shu (Beginner)
This certification indicates that the holder has comprehensive knowledge of how the Disciplined Agile solution delivery process works from beginning to end. To earn this Shu-level certification you need to pass a comprehensive test. It typically takes between 10 and 15 hours of classroom or reading time to prepare for the test. The primary benefits of this certification are that it:
Certified Disciplined Agile Practitioner (CDAP): Ha (Intermediate)
This certification indicates that the holder has comprehensive knowledge of how the Disciplined Agile solution delivery process works from beginning to end and has experience applying agile strategies in practice. To earn this certification you must have earned the CDA first, have at least two years of agile work experience (you are required to provide references), and you have passed the CDAP test. The primary benefits of this certification are that it shows you’re:
Certified Disciplined Agile Coach (CDAC): Ri (Expert)
This certification indicates that the holder has comprehensive knowledge of how the Disciplined Agile solution delivery process works from beginning to end, has experience applying it in practice, and has proven giveback to the community. To earn this certification you must have earned the CDAP first, have at least five years of agile work experience (you are required to provide references), and have gone through a board-level interview. The primary benefit of this certification is that it shows you’re qualified to coach agile delivery teams. Effective coaches must have deep knowledge in what they are coaching people in, and that requires proven experience.
RetentionTo retain your certification you should be dedicated to continuous learning of agile strategies in general, and in Disciplined Agile (DA) strategies in particular. Once someone is certified there are no direct membership dues. For CDA’s to retain their certification level they must take and pass the CDA test every two years. Having said that, at the two year point a practicing CDA is eligible to apply to become a CDAP anyway. Anyone with a CDAP will need to either pass the CDAP test every two years, or if they are qualified to apply for and become a CDAC. CDACs must provide proof of continuing give back to the DA community. Further Reading |