Three years ago I wrote an article that describes the changes in our Agile software development processes from 2008 to 2012. Three more years have passed by and our processes were not set in stone. Here I want to provide you with 90 months of changes in our product development practices, company culture, structure and engineering practices. Hope you will find it interesting and learn from our mistakes.
Read the article: Agile Software Development Process: 90 Months of Evolution
“I need this project done by date D and within cost budget C. Now calculate an estimate on the project.”
A friend of mine used this example to illustrate anchoring bias in estimation. Note, however, that he doesn’t make the question explicit. Further conversation revealed that he had in mind that the date and cost should be the output of the estimation. With that assumption, that statement preceding the request will definitely anchor the answer, and realizing that this bias is likely will call into question whatever estimate is given.
Given the stated need, however, I would reframe the call for an estimate from “When will this project be done and how much will it cost” to “What is the likelihood that the project can be done within these constraints?” When the time and money constraints are already known, it’s somewhat disingenuous to ask that these values be estimated. If the estimate exceeds the budget, then it’s likely that a negotiation will follow. Such a negotiation helps bring the estimate in line with the budget, but generally does little to bring the actual costs in line.
Reframing the question is much more helpful. It should provoke a response along the lines of “We feel 80% confident that we can meet the time and money budget based on these assumptions…. We have identified … as risks that would endanger meeting the budget and which should be monitored closely. Another possibility is that the response is of the form “There is a 10% chance that this project can be accomplished within the time and money constraints. If you’d like, we can explore finding a subset of the project that has a higher likelihood of completion but still have value.”
Either of these answers is more useful for the person with the budget who wants to decide whether to invest in the project or not. Sometimes the best outcome for a project is to kill it before starting when it’s unlikely to result in a happy conclusion. Other times we know to proceed cautiously, and can keep an eye on variables that will indicate whether we’re on a path to success or failure given the stated constraints. We should have alternate plans that we can turn to in the event that one or more of the risks materialize.
Such an estimate doesn’t guarantee success, but it does give us a feel for the merits of pursuing the endeavor. The associated assumptions and risks provide information to help us understand whether or not we’re still on track. This probabilistic estimate is much more helpful than is an estimate of the values.
Not all situations benefit from an estimate of the probabilities. We should think about what sort of answer would really help us, and ask the question that will produce an answer of that sort. Asking for “an estimate” without knowing and communicating the form of answer that will be useful is unlikely to give us appropriate information.
In a previous post, we talked about two ways customers approach test case management. In this post, we’ll focus on doing test case management with Axosoft Wiki.
QA teams approach testing in three main ways with Axosoft:
- The bulk pass
- QA team works through the same series of test cases before release
- Testing as a workflow
- Teams segment their testing phases via a series of workflow steps
- Testing all in one workflow step
- Teams use a “Ready for Testing” step to work through all testing for each item
In all three cases, you need to have your test cases written up in Axosoft Wiki. So if your test cases are written up somewhere as word documents, etc., consider organizing them with the Axosoft Wiki!Power up the wiki
Axosoft Wiki allows you to build out your potential test cases in an orderly fashion. Each test case can occupy its own page and thus be granted its own unique link found in the upper right of each page. Axosoft’s wiki is unified with your user story management and bug tracking functionality, which makes it easy to stay in one place for testing. No jumping between apps. No relying on one person’s machine to run. No processing requests to update test cases, etc.
Combined with Axosoft’s custom URL fields, you can start to see how you can easily link your QA people to the test cases they need to run. Let’s walk through the three examples mentioned above.1. Wiki and the bulk pass
Each release, you may have a large number of test cases that must pass testing before you can release your software to customers. These are likely the same test cases for each release. If so, then consider organizing these test cases in a template project folder with all the details included for each test case. Read this blog post for details on how to set up a template project.Here we have a sample test case template
Now that you have an idea of how to organize template project folders, we are going to add the wiki links. The easiest thing to do is to place the links in any large text field like we have displayed in the above screenshot. We like having the text field panel from the Details Panel docked to access the links quickly.
When release time comes, copy the template project folder and then add the test cases to your active release. This makes it easy to track their impact on the sprint via the Release Planner and to knock them out via your workflow. Then just rinse and repeat for the next release.2. Wiki and the testing workflow
Do you have a workflow to represent each stage of testing? If so, then you should be able to associate the appropriate test cases via associated workflow field templates. You may have seen the option to use a custom field template when you edit a workflow step as shown below:Each workflow step can get its own field template.
Create a field template for each stage in the test process. Within each template, associate the test cases required. Create a custom field with a Hyperlink input.Be sure to select the hyperlink option when building the field
Then insert the URL to the wiki page associated with this test case. Create as many as you need.This is how you copy the link for each wiki page for pasting.
Once you finish the templates, just match them up to the corresponding workflow step. Now when you move an item across this workflow, the appropriate test cases will be linked for reference.Here is the workflow
And here is what happens when you update the workflow step:This happens in the background when you drag and drop. Note the change in fields! 3. Wiki and the testing workflow step
This is like use case #2 but rather than testing requiring an entire workflow, you only need one of the steps to house any test case. Use a custom field template and associate it to the workflow step to provide reference to these test cases.One step might be all you need. Summary
Axosoft Wiki’s greatest feature is that it is unified with all your features, defects, tickets, etc. If you see other places where it makes sense to include a link, then try it out! For now, we hope this helps with your test case management.You might also like:
- Best Practices Webinar highlights
- Creating Project Templates
- Dashboards introduction
- Epics in Axosoft
- Help Desk in Axosoft
- Onboarding Tips
- Ranking your backlog
- Test Case Management
A few years ago I was at an Agile conference standing around with a bunch of CSTs and CSCs and one of the CSTs said:
“The other day in class, this guy asked me if he was Agile enough… can you believe that? What a stupid question. Who would ask something like that?”
Um… me… all the time. Even though I have now been working in Agile for almost as long as I worked in waterfall, I find myself often worrying that someone is going to find me out, or that my waterfall practices are so deeply engrained that I can’t even tell when they raise their ugly heads and start messing with Agile.
I am always concerned about being agile and getting better through practice. The Personal Agility Canvas is one attempt to help address some of my concerns. What follows is a written explanation of what it is, examples for use and how to apply it in your own meaningful way.
Where you start working on the Personal Agility Canvas does not actually matter. The ordering used below is based solely on how I normally go through each section. The main thing is just to start. I’ve personally found that it works much better when I avoid overthinking my ideas and begin filling the canvas with whatever comes to mind.Value Proposition
This is the box I usually start with when I am filling out the canvas. What goes in here should explain how you as an individual (not your team/group/department/company) add value. How would you respond if your boss was to lean his elbow over the wall of your cubicle tomorrow, coffee mug in hand, and say:
<Lumberg voice: “on”>
“Uh, yea, so, we’re Agile now and uh… we’re not really sure why we should have you keep working here so, um, you can go ahead and get set up in the basement next to Milton.”</Lumberg>
The question is, within your Agile(ish) organization, what unique value proposition do YOU (as an individual) bring to the table? What is it about you that makes you valuable to a company that has adopted (or is working on adopting) Agile?
Given that you want to change some aspect of yourself to become more Agile
When you are this more Agile you
Then how will you be different from who you are now?
When you evolve into this new version of you, how will this Agile version of you be able to add value to the organization? Or, how will your adoption of a more Agile approach better support the organization?
This can be a tough one. Most of us have spent time thinking about the value our company, our department, or our team adds, but we rarely take the time to consider the question as if we were re-interviewing for the job we already hold. And if you get really stuck, just ask yourself WWGHD (What Would Gene Hackman Do) “I tried to imagine a fella smarter than myself. Then I tried to think, “what would he do?” ~ Joe Moore from The Heist
So, try to imagine a more Agile version of you and ask how he/she would respond to the question, what value do I actually add here?
I come from a strong project management background and I’ve spent half my career learning how to work with Agile. I spent years fighting with Agile before it really made sense to me and the work I do. That offers me a somewhat unique perspective on adopting Agile. I see the workspace through an Agile point of view, but I also have a great deal of empathy for those struggling with the transition. My own personal transition was very difficult and that has helped me learn some things that I can use to help others get their heads (and hearts) out of the waterfall and into a mindset that is more in sync with the core tenets behind Agile.
Making the transition to Agile is not easy for an organization, or a department. And it is not easy for an individual either. If you are going to go down this path, you are going to have to expect some tough challenges. The process change is not easy, but it is nothing compared to the cultural and value system overhaul that it requires. In my experience, this holds true for those who REALLY want Agile to be more like the traditional way of working AND for those who read a book, drank all the kool-aid and found what they believe is the One True Way.
Change is not easy, and you are going to need a reason to keep going when things go all Sharknado on you. It would be easy to brush this one off and say your goal is to keep your job and that your company has mandated that everyone switch, but chances are, you’ll find it much easier to stick with this during the rough spots if you can come up with a specific thing you are trying to accomplish for yourself. So, what is your personal goal? Why do you want to go through this change? What’s the win for you (personally)?
- Do you have a specific goal for transitioning to Agile?
- How will you define/measure success?
- What indicators will let you know your goals have been achieved?
You may want to work in a more creative environment, or with a closely knit team that you can collaborate with. You may want to be part of a team that can deliver consistently. My favorite answer to this question came from someone who attended a workshop I ran on using the Personal Agility Canvas. He was an old school PM who was working with a team that had started using Scrum. He was struggling not just with a new way of working but with the fact that there was a whole new vocabulary he didn’t understand. His response “I just want to feel less stupid when I talk to the Agile people.”
One thing about setting goals, they need to be attainable. This is not the list of stuff you’d ask the Genie for after you freed him/her from the bottle. Your goals need to be few in number and they need to be realistically achievable in a relatively short time-frame. If there are too many, they are too grandiose or they are open ended, you may become discouraged and they will start working against you. A big part of this is not just achieving the goals, but developing the momentum you’ll need to keep working on transforming yourself.
Each of us has things about us that will propel us forward with the change that Agile brings. It is important to identify the strengths that you have because it is easy to get discouraged about making the switch. If you can identify a few things about yourself, how you work, how you think, etc., you can find a way to leverage these strengths to help you succeed with the goals you are setting for yourself.
- What about you, your mindset, and/or your level of discipline will help you during your journey to a more Agile you?
- What abilities, behaviors, personality traits, or habits will you be able to leverage to strengthen your successful transition?
- What experiences and/or training have you had that will serve you during your transition to a more Agile way of working?
Maybe you are someone who has experienced the strength of a good team first hand. Or you are someone who is just naturally open to experimenting with trying new things to see if they work better for you. I have a lot of experience in working with both Agile and traditional approaches of work. This experience has allowed me to see value in both ways of working and has led me to a point where I am less focused on process than I am on results (cough…outcomes).
I consider this to be a strength for two reasons. The first is that while I see value in learning new processes/approaches to work, I tend to not get so hung up on the idea of doing it “right”. It has also left me with a healthy skepticism. I take an empirical approach to how the different tools/methods/processes work. I do tend to start out trying to be disciplined about using a new approach, but trial and error wins the day in the end.Interactions with Others
How we interact with others is a big part of the cultural change that comes with moving to Agile. This can relate to how we communicate with people, our ability to trust, our openness to differences of opinion and our ability to be empathetic to others who may be further along, or not, than we are with making this change.
If you come from a traditional background, believing that you can trust others to make good choices in the work they do and in solving problems for the customer can prove to be difficult. A lot of this may just be about being mindful of how we talk to people and how we react to the possibility of failure. No one likes to fail, but it is important to remember that each failure creates an opportunity to inspect and adapt and succeed next time.
Consider the way you interact with others, how you lead and are led, how you communicate and how you think and feel about the people you work with.
- Are you practicing transparency?
- Are you willing and able to trust others on your team?
- Is this demonstrated through how you interact with people?
- Do you need to control things others do to ensure they are done right?
In the 1960’s, Douglas McGregor was working at MIT’s Sloan School of Management and he came up with “Theory X and Theory Y”. Basically, Theory Y assumes that if we give people what they need and the freedom to make a choice, they will work hard and do good things. Theory X, (not so much with the Agile), believes that if we do not offer the carrot and the stick (or often, just the stick), that people are inherently self-serving and lazy. Agile is much more in the Theory Y camp. One thing I had to recognize when filling this out was that while I REALLY want to be Theory Y, I have had a lot of work experience that pull me more into the Theory X camp. The way this plays out in my interactions is that if I am not careful I can easily slip into the “just do this because” mindset.
This is probably the easiest of all the boxes to complete. Consider your working environment, the tools you have at your disposal. In working towards a more Agile approach, do you have everything you need to succeed?
- Are there things about your working environment that aid or impede your ability to be more Agile
- What could (should) be changed to better support your transition to Agile?
- Are there things in play that could be amplified to enhance your personal adoption of Agile?
If your team is not collocated but are in the same building, maybe you want a space where you can all work together. If your team is distributed, maybe you need video conferencing for Daily Standups or a few big monitors to hang up so everyone can always see the task board. Or maybe you just need a rolling white board you can all share.
I use Personal Kanban to manage my work. When I am home and have my whiteboard, it works great. But, I travel a lot and I can’t bring the whiteboard on the plane. Yes, there are plenty of electronic tools out there, but most of them require internet access and they are no good to me at 30,000 feet. While solving this is still a work in progress for me, it is something that I know I need.
Also, because I love what I do, I have a tendency to want to say “HELL YES!” to every opportunity that comes my way. Work is important to me, but my family is much more important. I have learned the hard way that I need help with remembering to protect the time I have to be at home and fully present with my wife and daughter.The Mark Inside
In the book “The Ticket That Exploded” William Burroughs said “ Husters of the world, there is one mark you cannot beat: The Mark Inside”. Burroughs was referring to the fact that each of us, like it or not, is our own impediment. No matter how hard we try, we can never truly see ourselves outside of the narrative we create for ourselves about our own life. This is true in work, and it is true of our adoption of Agile. While it may not be something any of us can fully overcome, it is something we must be mindful of, always seeking understanding. Part of the relentless pursuit of continuous improvement that is inherent in Agile, is always trying to see the ways in which we are keeping ourselves from getting better. (Having an accountability partner can help a lot here see the end of this post.) In what ways are YOU the impediment to achieving your goals for a personal adoption of Agile?
- How trusting or skeptical are you in the “promise” of Agile?
- How disciplined are you in your practice of Agile?
- Are you hedging your bets because of “how things work in the real world”?
The trick with this is to try to develop awareness without judgment. For many, this is much harder than it sounds. If you have established goals for adopting Agile and you aren’t meeting them, are you able to see why? Maybe the goals were not realistic, maybe there are other factors that are contributing to your situation and you need to take those into account and reset. What you are working for here is a better understanding of how you are approaching the changes you are trying to make and learning more about yourself along the way.
I believe that once you learn traditional project management, it changes the way you look at the world. I am a project manager and I spent a lot of time refining my ability to see things that way. But, now I work in Agile. While I cannot un-learn traditional project management, I know that I need to pause for a few seconds to let the Agile filters kick in before I speak. The healthy skepticism that I listed earlier as a strength is also something that factors in here. I need personally validated proof in order to truly believe that changing how I work is going to help. While this is a strength, it also leads me to being a bit reluctant to just jumping on board with new ideas.
What are some possible areas of focus where you may want to introduce a change that will improve your ability to adopt Agile on a personal level?
- Behavior towards others
- Openness and Transparency
- Knowledge and experience gaps
- Willingness to Trust
Because of my experience working as a traditional PM, there are still language issues to be aware of – like referring to the humans who do the work as “resources”. I also have some gaps in the things I know about Agile that I continue to work on. And I know, that despite my best efforts, I still struggle with trusting that left to their own devices, and provided with the things they need, that people will do good things. I’ve gotten much better at this, but I still periodically run across situations that drag me back into the Theory X camp.
I have found that in working on this section of the canvas there are two things to consider. The first is to try avoid going from desired changes to negative self-judgment. The second is to keep this list reasonable. It is easy to come up with a bunch of stuff we all need to work on, but trying to maintain a list of things you can actually achieve in a relatively short time frame can be challenging. Be clear and keep it simple.
Transitioning to Agile is not an easy thing. There may be a lot you have to let go of and many of those things could be exactly what got you to where you are today. Change is scary and it is normal to be more worried about the devil you don’t know. So what about the possibility of Agile as a cause for anxiety or stress?
- Does the possibility of letting go of the things you have learned to do in work give you some angst?
- Do you worry that adopting Agile might have a negative impact when you start explaining to management you they aren’t getting a Gantt chart and that despite your PM Certification , you can’t actually be trusted to accurately predict the future?
- Are you seeing roadblocks or are you so deeply under the sway of responding to every impossible request by saying “YES” that you are stuck in the “Yeah, well, Agile sounds cool, but that will never work at OUR company because WE’RE special. “
When I first started working with people who were Agile, I was always scared that I was going to be caught or found out and exposed as a traditional PM. I dealt with this by trying to overcompensate for my traditional background. This completely worked against me.
Step 1: Take few minutes to review your Personal Agility Canvas. Come up with a list of 3 to 5 actions you believe you could accomplish in a relatively short time frame. These should be things you can measure and feel comfortable committing to and they should be focused on helping you reach whatever you are aiming for in terms of becoming a more Agile version of you.
Step 2: Write each action out, set a realistic deadline for each of the items and figure out how you will measure success, or define done for each of these items.
Step 3: Check your action plan against the goals you’ve set. Will the actions help you get there? If not, why and do you need to change one or the other.
Step 4: Go find an Accountability Partner. My suggestion is that the partner you find should be someone you trust to give you honest feedback and will be willing to call you out on things or challenge you when things seem off.
Step 5: Share your list of actions with your Accountability Partner. You don’t have to share anything on the canvas but the Action box. The rest may be fairly personal. When you share the actions, make sure to let your partner know about the deadlines you’ve set and how you will measure performance towards those goals. The job of the Accountability Partner is to check in with you if they have not heard back by the time the established deadlines hit. If you don’t hit them, that is between you and your partner, but they should be willing to challenge you on why if the goals are not met.
Establishing an Accountability Partner serves two purposes. The first is that your partner should be willing and able to serve as a sort of Personal Agility Trainer for you (like you’ve had in a gym). The second reason is a but dysfunctional but I have found that the guilt that comes from knowing someone will be checking up on me is a strong motivator.
Once you and your partner reach a shared understanding about their role, your goals and how you plan to achieve them, then it is time to get to work. You should expect that sometimes you’ll succeed with these things, sometimes, not so much. The trick is to continually inspect and adapt along the way. Should you decide to use the canvas, it would be great if you returned to this post and shared your experiences with the canvas.
Isn’t it fun to think about a future that includes driverless cars? The technology behind them is pretty impressive, but it isn’t quite where it needs to be to take over for humans. And in the meantime, we humans continue to be fallible creatures. We need instruction and practice to drive well, and even then, we sometimes get off-course or hit obstacles along the way.
(image: Flickr CC)
You know what’s even harder than driving a car? Driving an agile transformation. While agile principles may seem simple to understand, they can be complex to implement at scale. Changing an organization’s processes, practices, and culture takes knowledge, discipline, and motivation. Especially in large companies, guiding a scaled agile implementation can feel like steering a battleship with a joystick. This is why all successful change initiatives need great humans to drive them.The Cred to Create Change
We can train you to be a great driver. Our SAFe® Program Consultant (SPC) workshops will give you the confidence and know-how to lead an enterprise agile transformation. This four-day, intensive training will teach you how to harness the Scaled Agile Framework®, so you can accelerate change within large organizations and unleash the power of agile.
You’ll learn …
- The application of Lean, agile and product development flow principles for better productivity, quality, time to market, and employee engagement
- How to apply the Scaled Agile Framework, as well as how to teach and certify others in SAFe
- Certified leadership skills for unlocking people’s intrinsic motivation and leading a transformation
- How to identify value streams and organize Release Trains around them
- How to prepare the organization and its teams to launch Release Trains and run the first release planning
- When to interact at key program touchpoints, to help "keep the train on the tracks”
… Plus a whole lot more.Who Should Be an SPC
Our SAFe Program Consultant training and certification is a great course for internal agile change agents or external consultants. It provides the training you need to validate and implement your knowledge of agile programs, program portfolio management, agile architecture, and SAFe, so you can launch and steer an enterprise change initiative.
Your SAFe Program Consultant Trainers (SPCTs) are among the industry’s most experienced, hands-on coaches. They work regularly with a broad range of companies in applying their agile skills, honing their knowledge of leading-edge techniques, and identifying and resolving some of the most difficult organizational challenges. (Keep reading for a fact about our trainers you probably didn't know.)Get Started
Rally’s Agile University is offering SPC training and certification courses in four cities around the world, over the coming months:
- 15–18 September: Singapore
- 20–23 October: Dallas
- 10–13 November: Raleigh
- 17–20 November: Sydney
Visit the AgileU website to get the details.
Do you want to help other great humans build great organizations? Start by learning to drive, steer, and lead agile transformations. Sign up for our SPC training and certification course and get the skills you need to drive change with the right kind of impact.
P.S. Did you know that there are fewer than 25 SAFe Program Consultant Trainers, or SPCTs, in the whole world, and five of them work at Rally?Rally
I've written before that we should only estimate if having the estimate will change someone's actions. Normally, this means that the team should estimate work only if having the estimate will either:
- enable the product owner to better prioritize the product backlog, or
- let the product owner answer questions about when some amount of functionality can be available.
But, even if we only ask for estimates at these times, there will be some work that the team finds extremely hard or nearly impossible to estimate. Let's look at the best approach when an agile team is asked to estimate work they don't think they can reasonably estimate. But let's start with some of the reasons why an agile team may not be able to estimate well.Why a Team Might Not Be Able to Estimate Well
This might occur for a variety of reasons. It happens frequently when a team first begins working in a new domain or with new technology.
Take a set of highly experienced team members who have worked together for years building, let's say, healthcare applications for the Web. And then move them to building banking applications for mobile devices. They can come up with some wild guesses about that new mobile banking app. But that's about all that estimate would be--a wild guess.
Similarly, team members can have a hard time estimating when they aren't really much of a team yet. If seven people are thrown together today for the first time and immediately asked to estimate a product backlog, their estimates will suck. Individuals won't know who has which skills (as opposed to who says they have those skills). They won't know how well they collaborate, and so on. After such a team works together for perhaps a few months, or maybe even just a few weeks, the quality of their estimates should improve dramatically.
There can also be fundamental reasons why an estimate is hard to produce. Some work is hard to estimate. For example, how long until cancer is cured? Or, how long will it take to design (or architect) this new system? Teams hate being asked to estimate this kind of work. In some cases, it's done when it's done, as in the cancer example. In other cases, it's done when time runs out, as in the design or architecture example.Budgeting Instead of Estimating
In cases like these, the best thing is to approach the desire for an estimate from a different direction. Instead of asking a team, "How long will this take?" the business thinks, "How much time is this worth?" In effect, what this does is create a budget for the feature, rather than an estimate. Creating a budget for a feature is essentially applying the agile practice of timeboxing. The business says, "This feature is worth four iterations to us." In a healthy, mature agile organization, the team should be given a chance to say if they think they can do a reasonable job in that amount of time. If the team does not think it can build something the business will value in the budgeted amount of time, a discussion should ensue. What if the budget were expanded by another sprint or two? Can portions of the feature be considered optional so that the mandatory features are delivered within the budget? Establishing a budget frames this type of discussion.What Do You Think?
What do you think of this approach? Are there times when you'd find it more useful to put a budget or timebox on a feature rather than estimate it? Have you done this in the past? I'd love to know your thoughts in the comments below.
Phone screening junior candidates is hard. With 20+ years of experience I find it hard to evaluate someone who’s new to the field or worked less than 6 months. What I’m looking for is potential, but I can’t fall back on traditional measures where I ask for evidence of a skill. Sure they might have a beginning grasp of some language or the ability to put together a bare bones web site or iPhone app, but I really can’t drill them on OO, Domain Driven Design, or functional programming.
My approach has been to touch on some real basics to determine they’ve at least been exposed to subjects they claim on a recipe. Then I dig for stories of how they picked things up, what they learned from mistakes
Step one, is read the resume. They tend to actually be one page! Note anything I should ask them about such as basic language syntax or their explanation of TDD. Second, is take a look at any open source code you can find, often github. Ignore that it’s sloppy or untested and just take a good look at it. Then if you have time you can do some Googling and see what kind of data you can find about their participation in the community or even just questions on forums or Stack Overflow.
Next comes the actual phone screen itself. I have a stable of questions I use, a few I always use and many that I sample based on the interviewee’s experience:
- What have you done in 2 minutes or less? (I’ll let this go over 2 minutes if I’m getting good information, but sometimes you just have to tell people you need to move onto the next question.)
- I usually warm up with a question about the disadvantages of inheritance. This often throws junior candidates, but you can get a pretty good sense of how much OO they really understand this early in a career.
- As I’m a die-hard TDD/BDD type I always ask them to describe how they’d write a test in their current unit test framework. A surprising number of resumes that claim to practice TDD can’t explain the syntax behind writing a rspec or Junit test.
- I’ll often ask a question about a situation where they didn’t have enough information to complete an assignment and how they handled that. Sometimes this sort of behavioral question throws junior developers and I have to reiterate that I’m not looking for a theoretical answer.
- Then I’ll jump around from behavioral questions to technical questions. I might ask about what an index is or what they find most challenging about their current project.
- Almost always I include a question on how they come up to speed on new technologies. I’m looking here for anything they learned that wasn’t just presented to them in a class or at their job.
Finally I wrap up with a few standard questions:
- Why do you want to work for us?
- Is there anything else I should ask you?
- What questions do you have for me?
Every few months I come through the questions and usually add a few and remove the ones I never ask. I still wish I had a better process, but the most common theme to come out of junior phone screens is that they’re enthusiastic and they know at least what they claim on the resume.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
An A3 is more than an 11 x 17 inch piece of paper that is structured into several sections and not all A3’s are created equal. An A3 is a structured problem solving and continuous improvement approach, first employed at Toyota and typically used by Lean manufacturing practitioners. What your A3 looks like depends upon the situation. The example below consists of the following pattern, as part of an Agile Transformation:
- Current Situation & Problem
- Root Cause Analysis / Conclusion
- Corrective Action
After we agree on the four steps, we’re going to implement the correction action and then verify the results. The content of an A3 follows the logic of the Plan-Do-Study-Act (PDSA) cycle. What I want you to take away from this blog post is not so much TQM, PDSA, and A3’s, as much as how you could benefit from them when doing an Agile transformation or any kind of process improvement.
When doing an Agile Transformation, I’m going to always cycle back to 3 core goals.
- Form complete cross functional teams
- Build backlogs
- Deliver working tested software
Anything that gets in the way of doing these is an impediment that has to be removed. The example I have above describes how a team is under-committing each sprint. We’re using a story point completion ratio to know if the team is delivering working tested software. We’re going to use this single page to have a shared understanding with our client and agree on a course of action. Now, I’m not saying you have to use this template. If you can remove an impediment informally, by all means, do it! But, to make sure my client agrees there is a problem that needs to be prioritized and addressed, this is an effective tool and it’s pretty lightweight. You may also notice I don’t call this an A3 on the actual example. I’m going to call it an Action Report so my client feels comfortable with common language and I don’t need to distract them by introducing Lean terminology. When I say “A3″, there are certain expectations. Let’s not get hung up on that and just call it an Action Report going forward.Flow of the Action Report
You’ll notice that I structured my Action Report so that your eyes will be drawn to sections. I want to compare 1 and 3 (Current Conditions and Goals) and 2 and 4 (Root Cause Analysis/Conclusion and Corrective Action). This allows a transformation consultant to note impediments and identify root causes independently but then be prepared to collaborate with the client on goals and corrective actions. I’m going to stress this again. We’re only going to go through this process if the consultant can’t resolve the issue informally. If not, he or she will need to collaborate with the client to confirm the goal and agree on an appropriate action. The consultant doesn’t do all of this in a vacuum. When looking at action (or A3) reports used by others, I’ve seen them identify the goal prior to looking for root cause. From my experience, if I’m required to identify the goal before moving forward, this may create an unnecessary delay. If I don’t think something is right, I’m going to start investigating right away and then circle back with the client to validate their goal. But, I’m not going to stop and wait to be told what their goal is before beginning to look for root cause. I don’t want to stop until my personal curiosity is satisfied. Also, I’m not saying to not collaborate with the customer. I’m saying keep moving forward on multiple fronts and to circle back at the first logical opportunity.Current Conditions
We have several opportunities during the transformation to get this information. It could be, we just completed a formal assessment of the team or organization. Maybe we just reviewed metrics of the team or organization. Maybe I just walked out of a really long and unproductive meeting. Whatever we did, I’m looking for some kind of objective criteria or indicator to describe the condition.Root Cause Analysis / Conclusion
In order to propose appropriate corrective actions, we need to identify the root cause of the condition. Avoid using logical fallacies like anecdotal, appeal to emotion, or false cause. I like to use Socratic method or ask the 5 whys to help reach the root cause.Goals
The goal listed above in the illustration focuses on getting a team’s story point completion ratio to 100% +/- 10%. This goal is pointing back to building backlogs and delivering working tested software. By getting the teams to keep their commitments of delivering working tested software regularly, we allow the business to make better commitments to their customers. If we can build that trust and safety within our organizations, we’ll start to build balanced systems.Corrective Actions
Identify corrective actions that is both short term and easy to implement. If the actions are neither, I keep a higher level corrective action around and then break it down so I can incrementally work toward the goal. Personally, I keep my daily activities on a Kanban board. For an overall transformation, I keep the actions and activities in a rolling 90-day plan. This keeps the client informed on what value I’ve delivered and what value I plan to deliver in the coming weeks/months.Plan Do Study Act in an Agile Transformation
When doing an Agile Transformation, PDSA is just one pattern to map the approach. Not mentioned in this blog post are the original inputs into the initial coaching plan and 90-day plan. (both of which are collaboratively defined and continuously evolved with the client). But, how do I fit it all together in a high level “plan do study act” process, more emblematic of the original A3 process? I use the following:
- Coaching Plan (Plan)
- Rolling 90-Day Plan (Do)
- Adoption Assessment (Study)
- Metrics (Study)
- Action Report (Act)
I hope this provides some insights into how you can take some of the hand waving out of your next (or current) Agile transformation. There are a lot of moving parts and you need the process and tools to keep an eye on your goals and manage progress, without adding so much overhead that you stifle the forward momentum. Let me know if you have questions!
Download a free copy of the A3 – Action Report Template
Now see if words/expressions like "help", "become", "improve", "how to", "implement" "change", "need to", are part of your description.
If some of these are present in your description, take a moment and make two groups. Put those words that you used as applying to others, in the 1st group. Then put those that refer to yourself in a 2nd group . How many items are in the 2nd group in respect with those in the 1st one ? What these numbers tell you ? Well, I'll tell what they have told me. Help ( euh, and coaching ... ) Cannot Be Pushed On People If you're called to provide a given expertise when working with people and organisations, it might be tempting to "force in" your expertise. If you're successful , those people you're working with, will acquire the necessary knowledge to operate in the field of your expertise. Faster this will be true, more efficient you'll be. Simple as that, this is the end of the story, unless it's not. If would have been a dead end . Mandated expertise and "help" are some of those privileged impossible things that find themselves a cosy corner in the sweet spot of wishful thinking.
If I say ( e.g.) "I help organisation improve their team work" , it actually reflects my wish to be such a great professional who can help improve team work.
Help is the qualification of my work from my perspective. The same service I provide might be experienced by those that receive it (the helped people, you know ...) as little value overwork, meaningless noise ...
Real help can be qualified as such by people that received it.
That's why I know I'm no professional helper for any individual or organisation. I host containers that people fill in with their context and the change they want to see.
Well, if I'm not helping, let's see what may chances are to be a change enabler ...
Culture : From Values To Biases And BackNo change will happen until the culture will let it. OK, so focus on culture ! I do believe culture gives a group an identity . I do believe individuals influence culture . I do believe culture gives a sense of belonging .
Either you join a culture because its principles are aligned with your values, either you live by it( like the one you are born in) and learn to prise and nurture its values.
The set of values is the foundation of each culture . The set of common beliefs is the set of practices that result from prizing those values.Let's say we live in a culture that values "cleanliness" most. What will be our understanding of a culture that values "spare water" most? What will be their understanding of ours? What if instead of genuine observation we start to "rate" the set of values on a scale that has as reference our own values ? This is at least irrelevant at worst dangerous .
History have had some many, many tragic examples.
No change will happen until the culture addressed by that change will let it. If changing culture needs a shift in group's values, better start to shift my own ones. It's the "start with yourself" principle of congruence . This having being said, the task is in no way easier. If I start with myself, hmmm, let's say I've got this, what will I start with ?
Remember the "cleanliness" and "spare water" cultures mentioned roughly 10 lines above ?
"Liminal Thinking", a pattern defined by Dave Gray offers an alternative to "value the values of other cultures by our own values" . Great Stuff !
First we're invited to start the journey to ourselves by accepting a statement :
"The reality where I'm comfortable in, with my people, my cats, my umbrellas , my Agile principles ;) - is just set of beliefs I've built far from the real reality that, by the way, I don't even have a clue want it is".
From here, we can continue the journey into assumptions that created those believes , needs that generated those assumptions, experiences that we recall as relevant to our needs.
Why is this helpful ? Because we might realise why , and realise that other cultures have their own "whys".
I Have No Idea If I Help
If I'm in my group and my beliefs are my reality and of those I respect and care , why should I care if my reality is different of people that I might not care of and respect so much ? Because at some point, either their reality floods our cosy bubble , either I might have that fancy job description ( remember , it is now about 40 lines way up in this post ! ) that says I "help" other people change , and they might not be so wildly willingly to recognise me as the best next Messiah they can get.
If I stay in my own "Self-Sealing Bubble" I might get angry or frustrated because "they just don't get it".
If I inspect my bubble I can share the story of why I'm in and shake it to take a limp in the liminal space outside of it . Then ask questions and invite to answer, like Alice in Wonderland does. Alice is never angry , nor frustrated and has no idea if she shakes Wonderland.
Is this ... "help" ? Even farther, is this ... "help to change" ? I have no idea . That's why I'm not a change agent. When I first made the exercice I made up and proposed in the beginning of this post, now a far 60 lines up to the top, I fixed myself a goal : get rid of any of those words in the group that applies them to others . And get rid of them in the group that applies to myself , because they might be irrelevant to anyone but me.
To steal an expression I heard in a open Space chat at ALE2015 with my Trust Artist friend Olaf Lewitz I'm just "shaking" myself . See if anything happens.
Some Material To Promote Myself ( because it make me feel cool)
I held an workshop at the Agile2015 on Dave Grey's model combined with the archetype of "Third culture kids" to trigger awareness of our Agile self-sealing bubble :) .
The support is here
Related posts and other cool stuff Into The DNA Of A Culture
Agility Adoption Rather Than Agile At Scale
The answer to "Why" Is Ahead A Geography of Time , R. LevineThird Culture Kids, David C. Pollock
I recently received an email asking about release planning. The sender wanted help understanding how to move ideas through the flow to create a mature backlog. The note went on to ask how to properly “estimate, prioritize and reach an aggressive but realistic delivery date”.
My immediate thought was, this is agile: total project story points divided by team velocity yields the duration of the project. And delivery date then only depends on when you start and how well you manage risks and dependencies. If you want an “aggressive” or what I’ve come to understand as “overcommitted” plan you should just crack out your Gantt charts and stop pretending that you’re agile.
Before I dashed off a sharp email, I chatted with an associate and came to a different understanding of “aggressive planning”. He made the point that teams may not be aware of unused capacity. And establishing an accurate team velocity is a “trust but verify” process. Trust the current velocity, but periodically verify its accuracy. After a team establishes a sustainable and consistent delivery velocity, you should run an experiment. Increase the number of story points planned for a sprint by some number. If the team successfully delivers the sprint, then that total number of points is used for planning successive sprints. If the team sustains that pace, then reset the team’s velocity to the new number. Run the experiment again.
This cycle of experiments continues until the team can’t keep up. At that point you have verified the team’s velocity as the last consistently maintained pace. This final velocity is likely a bigger number (more aggressive) than the starting velocity number and so now a project’s duration will be shorter than calculated with the untested velocity. But the new velocity is verified; consider the date realistic.
Chances are, you or someone you know has “cut the cord” recently — canceled your cable TV subscription service in favor of the alternatives, like a set-top box, rabbit ears, streaming services such as Netflix and Hulu, or Internet-delivered media. Here in the United States, one survey found that more than eight percent of cable TV subscribers had cut the cord last year.
One thing you may not have considered is how this cord-cutting, multiplied by the thousands, is radically disrupting the cable and communications industry.
Swisscom, Switzerland’s leading telcomm company, was mindful of fast-changing industry trends when it decided to insource the development work for a new IPTV (Internet-delivered television) initiative. The company wanted to get its Swisscom TV 2.0 service out to the marketplace quickly, before its competitors; however, its organizational structure and culture were not set up for agile delivery.Laying the Groundwork
Bringing the development work for the IPTV initiative in-house was just one of many steps the company took to transform itself: it also built strong, cross-functional trust and transparency by co-locating developers with business owners, DevOps, and vendors across near-shore teams in six countries. Much of this groundwork already was laid when the company discovered agile a few years ago.“We simply did what made sense for us, and we figured it out as we went along. Only later did we realize that our efforts overlapped with existing practices for agile at scale.”
- Simon Berg, Agile Program Manager, IPTV EngineeringScaling Up
With support from Swisscom’s head of TV development and technology, the IPTV group adopted and scaled agile approaches: it implemented the Scaled Agile Framework® (SAFe®) and took advantage of Rally Unlimited Edition’s performance in tracking work at the portfolio level.“We chose the Rally platform for its portfolio-level management capabilities. No other solution could link strategy to execution across 12 teams, with rolled up visibility of multiple programs.”
- Simon BergLaunch Time
Swisscom launched TV 2.0 in 2014, and in just over a year racked up more than half a million subscribers — that’s more than 15% of all Swiss households. Meanwhile, Swiss cable companies have lost 98,000 TV customers in the past 12 months.
Swisscom’s agile transformation played a key role in the initiative’s success. The company cut development cycles from 12 months down to 3-6 months, and the teams’ use of agile testing and validation approaches improved quality and minimized rework. Perhaps most importantly, Swisscom didn’t just deliver on-time: it delivered the right product for the market. Being agile allowed the company to respond to shifts in direction and keep up with fast-changing consumer demands.“Ultimately, the culture and the people are how we innovate and win in an industry that is constantly being disrupted by new technologies.”
- Simon Berg
I keep seeing talks and arguments about how the portfolio team should manage the epics for a program. That conflates the issue of project portfolio management and product management.
Several potential teams affect each project (or program).
Starting at the right side of this image, the project portfolio team decides which projects to do and when for the organization.
The product owner value team decides which features/feature sets to do when for a given product. That team may well split feature sets into releases, which provides the project portfolio team opportunities to change the project the cross-functional team works on.
The product development team (the agile/lean cross-functional team) decides how to design, implement, and test the current backlog of work.
When the portfolio team gets in the middle of the product roadmap planning, the product manager does not have the flexibility to manage the product backlog or the capabilities of the product over time.
When the product owner value team gets in the middle (or doesn’t plan enough releases), they prevent the project portfolio team from being able to change their minds over time.
When the product development team doesn’t release working product often, they prevent the product owner team from managing the product value. In addition, the product development team prevents the project portfolio team from implementing the organizational strategy when they don’t release often.
All of these teams have dependencies on each other.
The project portfolio team optimizes the organization’s output.
The product owner value team optimizes the product’s output.
The product development team determines how to optimize for features moving across the board. When the features are complete, the product owner team can replan for this product and the project portfolio team can replan for the organization. Everyone wins.
That’s why the product owner team is not the project portfolio team. (In small organizations, it’s possible people have multiple roles. If so, which hat are they wearing to make this decision?
The product roadmap is not the project portfolio. Yes, you may well use the same ranking approaches. The product roadmap optimizes for this product. The project portfolio team optimizes for the overall organization. They fulfill different needs. Please do not confuse the two decisions.