Making sure external risks are addressed in an Agile effort, or any effort for that matter begins with making sure that at least a basic risk management approach is in place. If a basic risk management approach is in place we can integrate the concept of external risks. Everyone involved should understand the basics of the risk management process being leveraged on the effort. All risk management processes need to identify who is responsible and how the process fits into the value delivery flow. Specifically, incorporating the idea of external risks into the process is typically more urgent as the scale and duration of the effort increases if for no other reason than longer efforts are exposed to the trials and tribulations of the outside world longer than small efforts. The size of the effort affects two main variables used to scale Agile risk management. The larger the effort the greater the need for the people involved with the effort to define who is responsible for risk management and how much process is needed to keep things organized. The size of the effort, while a continuum, will be represented by small efforts (one team and a few iterations or sprints) and large efforts (over 75 participants with at least 6 iterations or sprints) for illustration. (more…)
September 15, 2016
March 31, 2016
Leave a Comment
Almost all human endeavors use a process architecture. Some of those architectures might not be immediately apparent, such as the scrum that often occurs at the beginning of a foot race or software development in a two-person start-up. Others, such as the product development in the medical device fields, are far more regimented. A mantra that many leaders in the software field utter is: “that we should only define just enough process.” It is easy to cobble together a process architecture that leads to common problems. It isn’t that anyone goes out of their way to make a mess out of process architecture, but it happens far more often than anyone would like. Common process architecture faux pas include: (more…)
March 29, 2016
Models, frameworks, and methodologies are like the three outer layers of a matryoshka doll. Once we have opened up the layers from models to frameworks and methodologies, components focused on defining “what” steps or tasks needed to build or deliver a product, the next set of layers shift to defining how to do a specific task or groups of tasks. The next three layers of our process architecture matryoshka doll are processes, procedures and techniques. Each layer is more granular.
Processes are the workhorses of the most software departments. Processes define well-documented, repetitive groups of tasks and decisions needed to achieve an outcome. A simple example of a process is the steps needed to hold a standup meeting. A process provides a view of the main elements needed to meet the processes business goals.
March 22, 2016
Models, frameworks, methods, processes, procedures, and the list goes on and on. Whether we are discussing Agile or plan based software development, works like methods, models, frameworks, processes and others are often used. The people that use these terms in polite conversation often assume or imply a hierarchy in these terms. For example, a model might include one or more frameworks and be instantiated in several methods. Each layer in the hierarchy breaks down into one or more items at the next level. Words and their definitions are an important tool to help understand how all the pieces and parts fit together and how to interpret the conversations about how software is developed and maintained in the lunch room or in hallways at conferences like Agile 2016. The unfortunate part is that few people agree on the hierarchy of models, methods, and frameworks. These words are often used synonymously sowing seeds of confusion and mass hysteria (ok , that might be a teeny tiny overstatement).
A proposed process hierarchy or architecture is as follows: (more…)
November 3, 2015
Whether you are working alone or in a collaborative office, finding a way to focus is important. I am currently experimenting with The Pomodoro Technique® as a tool to generate an environment where focusing is possible. In my experimentation, I have begun to hybridize Pomodoro to ensure I am working on the highest value activities in the right order and then to identify process improvements. I have added Kanban as a work entry technique and daily retrospectives to Pomodoro. (more…)
January 29, 2015
Leave a Comment
An Agile center of excellence (ACoE) provides support and energy to an Agile transformation within an organization. It supports through leadership, evangelization, best practices, research, support and/or training for agile and lean ideas. ACoE’s support can be categorized in three inter-related areas. These areas, the three “P’s,” are people, process and project.
People are the heart and soul of any development process. As we have noted, Agile has an enormous focus on people (remember the Agile value of valuing people over process). The ACoE provides support to people though bringing new ideas into the organization, by providing coaching, developing coaches and acting as change agents.
Agile is a set of processes, or sets of steps taken to achieve a specific end. A recipe is a process, as is a daily stand-up meeting or checking code in and out of configuration management tool. The ACoE supports Agile processes by capturing process, identifying and fostering the use of relevant metrics (collection and reporting are typically PMO functions – to be discussed in the near future), facilitating communities of practices and providing tools.
Projects are the currency of most IT organizations. At its simplest a project is an enterprise with a start and end that is organized to deliver a result. ACoEs support the performance of Agile teams at a project-level as coaches. Coaches are folks who deliver help to teams, stakeholders and other leaders within an organization so they learn how to be Agile. At the project-level, coaches help teams use and tweak processes to meet the team’s needs, provide training and support for tools and processes and help the team learn how to ask the hard questions about how the team is using Agile.
The primary goal of the ACoE is to provide practitioners with the tools, techniques and capabilities they need to be Agile. By helping teams perform, the ACoE also helps sell and maintain the Agile transformation. Both of these goals begin as an organization starts a transformation to Agile and continue to be important as teams evolve and continuously improve. The ACoE delivers value by addressing the three Ps. For example, through the role of coaching and by facilitating communities of practice, the ACoE helps to promote an environment where there is consistency of practice and where innovation can happen. While the combination of innovation and consistency might sound contradictory, coaches often act as an Agile Johnny Appleseed. ACoE coaches see how teams work, the changes that have made to the processes and why those changes were made. The ACoE can then help to spread ideas that prove to be valuable through coaching, referrals or discussion in communities of practice.
December 26, 2014
Developing or maintaining a piece of software requires a fairly complicated set of processes, including processes for collecting requirements, designing, coding, verifying and validating a solution. All of the processes need to work together well or they risk impacting the quality of the delivered product. Process problems tend to be most severe when testing and engineering processes are mismatched, organizations embrace a one-size-fits-all testing solution or ad-hoc testing processes (gag).
- Mismatched processes – Testing is a collaborative process requiring communication between everyone involved in developing software. When development and testing processes are not synchronized, the chance of miscommunication increases. For example, consider the communication problems that would ensue if the developers were using Agile techniques while the testers were using waterfall techniques. Agile development techniques would be focused on delivering functional code rather than omnibus requirements or design documents that are often used to drive waterfall testing. Whether Agile, waterfall, RUP or some other framework if testing and development have not found a mechanism to synchronize how they work together, defects will make it to production.
- One-size-fits-all testing solutions – Every project has its own set of nuances and risks. The testing solution for each project needs to be tailored to meet the specific needs of the project. A one-size-fits-all solution will tend to overemphasize specific types of testing (e.g. functional testing, system testing or integration testing) when another type may need emphasis. For example, recently I observed a large program that initially failed on delivery because integration testing was not part of the standard process the firm used.
- Ad-hoc testing – Ad-hoc testing (just winging it) went out of style as soon as someone thought about the quality of the code being delivered, it never worked and never will. Just don’t do this.
Development is a dance of multiple inter-related processes. Regardless of whether the project uses the team uses a mixture of extreme programming, test-driven development, black-box testing or exploratory testing the processes need to work together. Synchronized and compatible development and testing processes are critical for effectively and efficiently developing. Agile techniques leveraging cross-functional teams, that include developers and testers, put teams in the best position to ensure a synchronized process.