Blog

Advanced Release Charting Template – Part 2

By: Agile Velocity | Jul 01, 2014 | Article, Scrum

In the first part of this blog series, we introduced the Advanced Release Chart Template and discussed how to communicate progress to customers and stakeholders using burnup and burndown charts. The second and final part of this blog series drills into the details of what’s being delivered in the release to help drive decisions and answer more specific questions about scope. Specifically, we’ll focus on prioritization and forecasting against the product backlog.

Prioritization (Working on the Right Things)

Forecasted burnup and burnup charts are usually the appropriate level of information to communicate progress to people interested in knowing if you’ll “hit the date” or “when the work will be completed”.

Those charts display how much work was completed and what effort is remaining, but it doesn’t communicate if you’re working on the right things. It treats the release backlog as one single unit and offers a binary response to the questions:

how much will be delivered by x date?
when will y scope be delivered?

If you are strictly focused on output, then answering these questions is sufficient. We offer a way to look inside the backlog to drive decisions about what’s really important.

Effort by Priority

Many times we try to discover what’s really important just to be told that “it all has to be done”. Rarely is this really the case. More often, it’s a matter of not having the information necessary to drive decisions or fear of damaging a new relationship with an important customer.

The product owner is responsible for driving prioritization with stakeholders and customers. We advise many of our customers to adopt a very simple prioritization approach called MoSCoW, which is comprised of 4 priorities:

Must
Should
Could
Won’t

It’s a simple and established mechanism and it gets people to start dividing the release scope into categories to help prioritize the work. The priority is applied each user story in the release backlog often requiring the addition of a custom field in your Agile Project Management software.

Let’s take a look at some examples.

This pie chart looks suspicious since almost all of the scope is categorized as “Must”. While it might be true, particularly in a fixed scope project, it’s more than likely wrong. Charts like these can help drive discussion and lead to decision making about what’s really important.

Hopefully, those discussions will lead to a chart that looks more like this. At a glance, it appears to have a good mix of priorities reflecting the fact that people are making decisions about the scope. It also does not display any features that “Won’t” be built. “Won’t” is a useful priority, but you’ll rarely see those reflect in your chart since those are intended to be cut from the release scope.

Assigning priority is one way to define the importance of the release backlog items.

Effort by Feature, Epic or Initiative

Another way to evaluate if the release is focused on the right outcome is to look at what you’re getting for your investment in a category. Category is being used to indicate any meaningful grouping of user stories that conveys values to your stakeholders or customers. Some other commonly used synonyms are: epic, feature, or initiative. Whatever terms you use the effect is the same which is to evaluate return on investment.

The chart above is based on the categories identified for a Lego City backlog. In other words, when building a city using Legos where are we investing our time? The data shows a reasonable portfolio that shows a proportional investment needed to create a livable city. We might want more information about what value is being delivered in “Other” or wonder why “Transportation” is so much smaller than “Entertainment”. The point is to quickly identify if the effort or investment is proportional to the value. If it’s not, then drive discussion about how to correct the imbalance by adjusting the release backlog.

Backlog Item Forecasting (Low-Level)

Product owners and managers need a more detailed view of their backlog so they can add, change, delete, and reorder the backlog items. All Agile Project Management software offers this capability, but it may or may not provide the view you need to really understand it. To this end, we offer our ‘Product Backlog’ sheet as a place to export your backlog from your software so that you can understand it better.

The data provided at this levels allows for filtering, is needed to populate the charts described earlier, and provide confidence indications at a detailed level so you can answer the question “which features will make or not make the release”.

Drawing on the previous sections, we can see a full release backlog with the following characteristics:

ordered by their confidence to make the release; the backlog items are ordered as follows
- completed work – anything finished will be in the release
- active work – anything in progress is expected to be completed and make the release
- new work – ordered by value and dependencies; may or may not make the release
confidence lines drawn against the backlog, using cumulative effort, so you can provide your confidence that a feature will or won’t make the release
- green – 90% (new or active) or 100% (completed) confidence
- yellow – 50% confidence
- red – 10% confidence
- grey – 0% confidence; will not make the release
order, priority and effort are visible for each backlog item

Using Our Template

All of the charts presented in this article are driven by the ‘Product Backlog’ worksheet which is a detailed view of the backlog populated from your Agile Project Management Software (e.g. TFS, Jira, Rally, VersionOne, etc.).

The backlog expects the following fields to be exported from your software:

ID – some unique identifier for a product backlog item
Priority – any set of values that distinguish importance of backlog items relative to each other (e.g. MoSCoW).
Order – a value that indicates the order of a backlog item relative to another backlog item; retains the order found in your Agile Project Management tool
Category – a grouping of backlog items such as an Epic; some tools do a better job than others allowing you to export this data
Title – the name of the backlog item or user story; something descriptive so you understand what it is at a glance
Story Points – an estimate of the effort required to complete the backlog item
State – has the backlog item been completed, is it in progress, or has it not been started?
Tags (optional) – not required but may provide another way to filter the backlog

The remaining fields in the ‘Product Backlog’ sheet are automatically calculated. Until the Agile Project Management software provides these capabilities we hope you will find our Advanced Release Charting Template useful.

Advanced Release Planning Template – Part 1

Blog

Advanced Release Charting Template – Part 1

By: Agile Velocity | Jun 26, 2014 | Article, Scrum

In October 2012, we released our first downloadable template to help forecast and chart release progress. Since that time, we’ve helped many organizations transition to Agile and found some recurring needs that have driven the creation of the Advanced Release Charting template:

Set expectations about deadlines and report to stakeholders. Will the desired scope be done by the deadline? Is the project still on track? How can we ensure successful delivery? What should we tell our customers? What work has been identified but not estimated (i.e. not reflected in the forecast)?
Prioritizing the backlog items within large projects. All too often projects are seen as all or nothing when in fact there is room for discussion about the importance and impact differences. Are you working on the right things? Are they all valuable? Is the investment proportional to the value?
Backlog items are often too small to report against. Customers and stakeholders are more interested in understanding which high-level features are at risk or how they are progressing.
Product owners need to a better way to look at their backlog and understand which items are least likely to make it.

In the first installment of this two part blog series, we will focus on high-level release planning and tracking. Understanding how to communicate at this level is the first step in managing expectation with stakeholders and customers.

Release Forecasting (High Level)

Each release has a vision, objectives, and pressure to deliver against commitments. These commitments come in the form of scope, schedule, or both. In Agile, we value frequent delivery which allows us to regularly communicate progress and manage expectations with customers and stakeholders.

Each release has a set of constraints and we encourage our customers to define a project trade off matrix to identify which constraints are fixed, chosen, and adjustable. Once these are understood we can pick the right model to report progress, such as fixed date or fixed scope burn charts.

Fixed Date Release

Fixed date releases combine the pressure to deliver with the flexibility to negotiate scope. When a release date is fixed progress comes in the form of completed scope and expectations are set by forecasting how much of the remaining scope is likely to be delivered. We provide a Forecasted Release Burnup chart to review the health of the project, at a glance.

Let’s take a closer look at an example.

In the burnup chart above, the release has a fixed schedule of 10 two week sprints, or 20 weeks. The project started on February 25th with a planned scope of 70 units of effort, often measured as story points in Agile organizations. The team responsible for the release has already completed three sprints and has begun their fourth. What can we tell by looking at the chart?

First, it’s clear by looking at the planned scope line that the amount of required effort for the release is increasing. What it doesn’t tell you is why. Many people might quickly conclude that the product owner has accepted additional feature requests from their customer and the team is being asked to deliver even more work. This might be the case, but there are other possibilities. In Agile, we replace big up front planning with just enough planning at the start and recurring planning based on continuous feedback and learning about what’s needed to deliver the right outcome. With this in mind, the increase in planned scope could reflect revised estimates provided by the team after they gained a better understanding of the work.

Next, we turn our attention to the actual and forecasted output. In Agile, we recognize that we cannot perfectly predict what or how much will be delivered in a fixed date release. Instead, we communicate a range of output based on risk multipliers or optimistic and pessimistic trend lines.

In our sample burnup chart, you can see that we are communicating that the team will deliver somewhere between 52 and 78 unit or points of effort by the end of Sprint 10. You’ll also notice that there is a gap between the planned scope and the scope that we forecast with 10% confidence. The gap against the forecast that has 90% confidence is even wider. So what can we do?

Before we consider our options, let’s examine the data on the chart further. Notice that as sprints are completed our output reflects actuals and only future output is forecast. In this case, you’ll notice the team has completed about 27 points after 3 sprints, or an average velocity of 9 points each sprint.

Now let’s look at some possible options to explore by themselves or in combination:

The team is outperforming our expectations, with a velocity of 9 points instead of 7 points, so let’s adjust our expectations based on their performance. If we increase their velocity to 9 points, then the forecasted output tilts upward and we gain confidence in our ability to deliver the planned scope.
We recognize that the team has some upcoming vacation and that the original velocity of 7 points already takes these types of outages into account. Consequently, we leave the velocity and look to address the mismatch in scope another way.
We cut scope by agreeing on the least valuable features. This may even involve the compromise of releasing some of the higher value features earlier to gain an earlier return on investment.
We identify another team with sufficient knowledge of the product to deliver a subset of the features while keeping the existing team focused on the remainder of the release backlog.
Perhaps new information drives us to understand that the release date can be pushed out after all and we extended the release by one or two sprints to deliver the desired scope. While this goes against the notion of having a fixed date release, it acknowledges that circumstances can change which might alter constraints.

The data provided by the burnup chart allows these discussions to occur to determine the best course of action. Consequently, the chart is updated at least once per sprint and communicated to stakeholders to manage expectations.

Fixed Scope Release

With an understanding of how to read a burnup chart, it’s easy to flip the constraint to a fixed scope and range of dates. For this we use a burndown chart, as shown below.

Burndown charts allow us to forecast potential dates for the release. In the example above, we need a further date horizon to identify the range of actual dates. So far we can only tell that it will take the team longer than 10 sprints, and probably around 12 to 15 sprints, to complete the planned scope. Even a fixed scope release, will undergo some amount of discovery by the team leading to revised estimates. In the case those estimates are larger, the remaining scope will be a combination of the actual work completed and the increase in effort.

Undefined Effort

The burnup and burndown charts reflect the work that is known and estimated by the team. As the project progresses additional work will be discovered and the team will continue to provide estimates. Sometimes those estimates lag behind the identification of new work. The more unestimated work the less information people have about the health of the project.

The simple pie chart above shows that 20% of the user stories or requirements in the release backlog have not been estimated. How does this information change your perception of the project? Should you reserve some of the team’s capacity in the next sprint to estimate the remaining work? Would it be better to find places to cut scope now realizing that the estimated scope is already at risk?

Using Our Template

Our template is simple and easy to use and allows you to use a burnup chart, burndown chart, or both by updating just a few fields each sprint on our ‘Data’ worksheet. The charts are automatically updated to reflect the changes without any need to understand the formulas involved. We also allow you to define your cone of uncertainty (i.e. range of outcomes) using either industry established risk multipliers against velocity or establishing your own confidence intervals based on past or expected performance.
The pie chart of estimated and unestimated user stories is driven by the ‘Product Backlog’ worksheet which is a detailed view of the backlog populated from your Agile Project Management Software (e.g. TFS, Jira, Rally, VersionOne, etc.).

Advanced Release Charting Template – Part 2

Blog

Lean: Purity vs. Pragmatism

By: Agile Velocity | May 19, 2014 | Article, Kanban, Lean

“That’s not Agile and Lean!”

“We’re not being lean enough.”

“We’re not supposed to make deliverables!”

Sound familiar?

I hear these statements all the time from teams moving towards a more evidence-based approach to product discovery, conception, and production. Somewhere, someone made a decision for the teams to now “do Agile & Lean” and so, books were bought, conferences attended and index cards purchased. The teams set off with a healthy mix of trepidation and optimism and began practicing the newly learned processes – visions of stand-ups, post-it notes, IPM’s and validated learning in their heads.

Except it’s never that clean.

Something gets in the way. Something gets in the way – reality. Reality consists of:

The client (or stakeholder) who doesn’t really understand what being agile actually means demanding roadmaps, and sitemaps, and journey maps and story maps.
The project budget, which is allocated not just for discovery but also for actual production of a software application.
Distributed teams who struggle to maintain transparency and real-time conversation.
Experiment results that don’t give a clear indication of next steps.
Technological constraints that won’t allow production-level scaling of the optimal solution.
A corporate culture that frowns on failure and makes collaboration difficult

And so much more…

What is the newly minted Agile/Lean team to do when faced with these harsh realities?

Do you push through, sticking only to the fundamentals in the books and tutorials hoping things will work out? Or do you take the pragmatic approach and adjust as needed to accommodate the realities on the ground?

The answer, of course, is the pragmatic route. Each project, team, product, company, industry and market brings with it its own context. These contexts demand a unique approach that can’t be predicted in a book or manifesto. The frameworks articulated in those books are starting points. Once they get wrapped in these contexts they will inevitably morph.

And that’s OK.

Ultimately, what you really need is to ship product. Lean and Agile will help you gather evidence, determine more successful paths, produce working software faster and build a shared understanding between your teammates, clients and stakeholders. Start with these philosophies. Use them to build evidence, insight, direction, learning and value. But keep this in mind – there is no scale for agility or lean-ness. There is no such thing as not being “lean enough” or “agile enough.”

This blog article is reprinted with permission by Lean UX author, Jeff Gothelf.

Jeff Gothelf is an agile product designer, teacher, writer and team leader. He is one of the leading voices on the topic of Agile UX and Lean UX. In addition, Jeff is the author of the O’Reilly book (2013), Lean UX: Applying lean principles to improve the user experience. He is a highly sought-after international keynote speaker, workshop leader and trainer. Currently, Jeff is a Principal at Neo Innovation in New York City.

Blog

Building In-House Agile Innovation Teams: Transparency

By: Agile Velocity | Apr 29, 2014 | Article, Lean, Team

In the first post of the series, I discussed the basic building blocks of a successful in-house innovation team: small, dedicated, collocated, and self-sufficient. In this post, I’m going to talk about a key philosophy for these teams: transparency. It’s not in our nature to be transparent in the business world (or in the personal world for that matter). From the baseball diamonds of little league to the lecture halls of business school, we’re taught to be competitive and to push ahead of our colleagues. After all, it is our individual ideas and skillsets that define the quality of our work and our discipline and set us apart from our colleagues. How can being transparent – with our thoughts, our tools, techniques, and ideas – possibly help us excel as individuals, as a team, and as a company?

Transparency at the individual level

The first place to start, as with all of life’s improvements, is with you. Regardless of your core competency – design, engineering, management – sharing your ideas and techniques with your team early and continuously brings a whole host of benefits.

Validation of your ideas – making your ideas public early gives the team a chance to weigh in and provide their insight into the feasibility, relevancy, and validity of your thinking. This, in turn, saves you time by keeping you from exploring ideas that don’t align with the team’s vision or scope.

Collaboration – the act of sharing by itself begins a dialogue with at least one other person on your team. As that conversation, and that technique, spread beyond that initial action a spirit of collaboration takes root. In addition, you are seen as someone to whom others can seek out for feedback and further collaboration.
Thought leadership – transparency shows you’re actually getting work done (we all knew that, but it can’t hurt to show it). If you’re working on the project then you’ve likely generated ideas on how to approach it or solve the current problem. This paints you as the “idea person” and someone who has put in the time figuring the challenge out.

Source of inspiration – Your ideas, now visible to everyone on the team, serve as a starting point for feedback and discussion as well as inspiration. Teams react to initial ideas, even if they’re straw men, rather than blank whiteboards. In addition, your efforts at being transparent may inspire others on your team to be more forthcoming with their early thoughts.

Transparency at the team level

Teams, especially those trying out new ways of working, benefit greatly from open-sourcing their processes. In many ways, without even trying, transparent teams become mini-R&D units for new thinking, processes, and products. This recognition would be far more difficult to come by if the team closely guarded their internal IP. In addition, team transparency brings:

An awareness of new techniques – if some of your colleagues could benefit from a new customer interviewing technique you’ve used or a way to measure the impact of certain architectural changes, hold a brown bag lunch, and demo your new technique. Letting others see what your team is doing and how it’s working (good, bad, or otherwise) saves them the time it would take to learn those things on their own.

Consistent status updates for managers and above – nothing makes managers more anxious than not knowing what their team is currently up to. Using techniques like daily standups, weekly status updates, information radiators reporting back on the team’s success metrics, and weekly demos your managers will always be ready to answer their boss’s questions about your progress – which will keep them out of your way. Nice.

Comfort with a team’s progress (especially if measured differently) – I talk a lot about lean teams and how they should be measured against business outcomes, not a specific output. This new way of measuring is difficult for managers since it is not binary (e.g., did the feature launch or not?). By ensuring your team is consistently communicating their progress against their targets (even if the progress is not good) it gives your manager a sense of how you’re progressing. In addition, it’s important to let your manager know what you’re working on this week, what the backlog holds for the next iterations, what you’ve learned in your recent experiments and what you hope to test next.

Reduction in roadblocks for colleagues and other departments – the marketing department wants to know when you’re launching new features. The customer service folks need to know when workflow updates are going live. These folks are not trying to get in your way. They’re trying to do their job. Make it easy for them (and for you) by always communicating to them what you plan on releasing, when, and how it will affect their day-to-day work. This holds true for any department that’s dependent on the product you’re developing.

Greater sense of pride and accomplishment – if your team succeeds and has been transparent about how they succeeded, they can continually point to those successes as proud accomplishments. That sense of pride is contagious. Other teams will want it and will reach out to your team to understand how you did it and perhaps even ask you to help train their crew.

Transparency at the department level

The word department is often synonymous with the word silo – especially a discipline-specific silo. There are other types of departments though – usually product lines or industry verticals serviced by the organization. Transparency at this level – regardless of the type of department you work in – can have a dramatic impact on the way the organization perceives your department as well as the impact you can have on the organization itself. By making the company aware of the processes your teams follow, sharing insights into the specific tactics those teams use, and broadly posting the various teams’ progress towards specific business objectives your department can become a vision of what the future holds for the rest of the company. Let’s take a look at some specific impacts.

Hiring brand – every department wants to hire the best practitioners. Being transparent about how you achieve great results, what kind of empowerment employees have, and how everyone is measured and rewarded indicates a level of trust that many A-players value. It clearly indicates that your department does not micromanage and allows employees to push boundaries without fear of retribution.

Thought leadership – as the organization learns more about what your department does and how it’s faring in its business efforts the perception grows that this is the department that is leading the organization both on domain expertise as well as process.

Greater effect on company/product strategy – the mythical “seat at the table” becomes a far more realistic achievement for your department when your leadership understands what it is you do and how you do it. In addition, there is a greater confidence in the strategic suggestions your department makes to the organization because it is based on widely-available learnings you’ve socialized internally.

Transparency at the company level

Transparency at the organization level works in two directions – internally to your employees and externally to your customers. For the purposes of this article, I’m going to briefly focus on internal transparency. For external transparency and other insight into how to build successful companies you should read Dave Gray’s The Connected Company.

Internal transparency gives your employees a clear sense of how the business is doing and how their work is impacting that success. It motivates them to fix problems they can clearly see impacting revenues, customer satisfaction and other success metrics. It demystifies the “executive layer” and shows the rationale behind the decisions that come down from the C-suite. Finally, it encourages employees to be good corporate citizens and to dig into business intelligence data to find opportunities for improvement or to diagnose the root causes of problems they are tasked with fixing. Ultimately, it shows your teams that the company’s leadership trusts them.

Successful innovative teams and companies share their learnings. They share their successes and their failures. They’re honest about what they’ve tried and what they’ll try next. They build collaborative eco-systems that feed fast learning cycles and cross-pollinate innovative insights across the organization. It’s this transparency – at the individual, team, department, and company levels – that empowers innovation teams to succeed.

This blog article is reprinted with permission by Lean UX author, Jeff Gothelf.

Jeff Gothelf is an agile product designer, teacher, writer, and team leader. He is one of the leading voices on the topic of Agile UX and Lean UX. In addition, Jeff is the author of the O’Reilly book (2013), Lean UX: Applying lean principles to improve user experience. He is a highly sought-after international keynote speaker, workshop leader, and trainer. Currently, Jeff is a Principal at Neo Innovation in New York City.

Blog

Behavior Driven Development: Steps to Implement, Part I

By: Agile Velocity | Apr 14, 2014 | Article, Technical Practices

Behavior Driven Development is the process of writing high-level scenarios verifying a User Story meets the Acceptance Criteria and the expectations of the stakeholders. The automation behind the scenarios is written to initially fail and then pass once the User Story development is complete.

BDD is largely a collaboration tool that forces people working on a project to come together. It bridges the gap between stakeholders and the development team. Practicing BDD is fairly painless but does require a meeting to discuss the intended behavior the scenarios will verify. The meeting to write the BDD tests is usually an informal one which is led by the Product Owner or stakeholder and involves members of the development team. The goal is to collaborate so everyone is on the same page as to what this User Story is trying to achieve: Start with the story. Talk about the “so that”. Discuss how the software currently works and how this story will change or impact current functionality.

Scenarios are written from a user’s perspective. Because they are run on a fully functioning system with real data, they can be expensive (meaning the time it takes to write, execute, and maintain the tests). However, the scenarios will serve as executable documentation for how the software behaves. This is useful for developers to understand each other’s code and gives them tools to refactor with confidence. Over time, the tests will evolve as they are maintained and also serve as easy-to-read descriptions of features. Documenting behavior in this manner is useful when onboarding new team members by communicating the software’s functionality.

Things to ask yourselves when writing scenarios:

* What functionality is not possible or feasible to cover with lower-level automated tests? How do these tests differ from unit tests, integration tests, or service tests?

* What is the “happy path” of the User Story functionality? This is the typical usage of the software.

* What is the atypical usage? Are there variations of inputs that are possible, but used less frequently?

* How should the system handle bad input?

* How does the system prevent bad output? How does it display or log errors?

* What is the impact on other parts of the system?

* What are the integration points – other components, other applications? Should the tests include some verification of this integration, or is it covered elsewhere?

What Works Well

The process that has worked well for me is to, first, write the scenarios together with the Product Owner.

The PO should lead this discussion and write the steps in a way that makes sense to stakeholders. At least one Developer and one Tester should also be present. Some like to call this the “Power of Three”. Read through the Acceptance Criteria asking the questions listed above. Try to use consistent language in the steps and use terms that make sense to people outside the development team. It may be tempting to write steps involving user interaction with the software, like this:

Given I am on the Login screen
When I enter “user1″ in the username field
And I enter a “mypassword” in the password field
And I click the Login button
Then I should see the error message “Username/password is invalid”

I have found, it is better to describe the behavior in broader terms not closely tied to the application layout itself. For example:

Given I am on the Login screen
When I enter invalid credentials
Then I am not logged in and a meaningful error message is displayed

This way, the code behind each step is closely tied to the application or the user interface, not the test scenarios themselves. As the application grows, the test steps themselves will be less likely to require changes, isolating the maintenance to the code behind the test scenarios.

In the second article in this series, we’ll discuss what to do once the scenarios are defined.

Tool references: http://cukes.info/ (Ruby)

http://www.specflow.org/specflownew/ (.NET)

http://jbehave.org/ (Java)

Blog

Behavior Driven Development: Steps to Implement, Part II

By: Agile Velocity | | Article, Technical Practices

In the first article of this two-part series, we discussed how to define scenarios for testing. Now, once this is done, the Testers can partially implement the new steps to fail.

For example, adding assertions that a file exists on the file system.

Or, writing code returning a negative result for now.

Maybe the code will eventually query the database to return a positive result, or maybe it will ensure some value is displayed on the UI. Sometimes this part is minimal; sometimes it can include almost all of the step implementation.

Lastly, during feature implementation, the Developer writes the final test code to make the scenario pass.

I encourage Developers and Testers pair at this stage. This type of teamwork keeps the Tester engaged in how the code is being implemented and ensures they understand how the software works. An informed Tester is a good Tester.

As you probably know, automated tests provide more value the more frequently they are executed. This is why you want to be smart about the tests covered at the user level. Automated testing is an investment. The team should view the tests as code as well.

Automated tests require maintenance to keep them passing and best if shared by all members of the team. When practicing BDD, make sure all scenarios provide value. They should not be too difficult to automate. Be careful not to include too many variations of input data. If possible, cover the various inputs using tests at lower levels: unit, integration, service-level. Use the BDD scenarios to cover what is not, or better yet, cannot be covered by other types of automated tests. Don’t be afraid to get rid of a scenario altogether if it doesn’t provide value. It is okay to run some tests manually as long as the team understands manual tests are executed much less frequently, so feedback is delayed.

Tips for BDD:

* Write them to be executed locally on a Developer’s machine
* Monitor execution time and keep it to a minimum
* Scenarios should not be dependent on each other
* Scenarios can be executed multiple times in a row and still pass (some cleanup may be necessary)
* To keep the number of steps from getting out of hand, pass in variables to the steps to maximize reuse
* Keep your steps organized in separate files by major functional area
* Scenarios are grouped to allow for a quick regression test of each major functional area, or a full regression of the entire system
* Use source control for your test code

When BDD is done properly (before implementation), the real value is gained by simply collaborating and discussing the expected behavior of the software!

Once implementation is done, the scenarios ensure the software meets the needs of the stakeholders. From then on, the automated tests act as a safety net for developers to refactor code and implement new features with confidence.

Teams should strive to make execution of at least a portion of the BDD tests part of their Continuous Integration build/deployment process and make the test results visible. Failing test scenarios around existing functionality should be a top priority to fix.

Have fun!

See Behavior Driven Development Part I

Other resources for BDD:

Tool references: http://cukes.info/ (Ruby)

http://www.specflow.org/specflownew/ (.NET)

http://jbehave.org/ (Java)

Blog

Tips to Enhance Your Agile Career

By: Agile Velocity | Apr 02, 2014 | Article

Have you ever wondered if you are being utilized to the best of your abilities?

Are you being held back from that role you feel you deserve?

When is it the right time to make a proper exit from a company for career development?

In my experience talking to thousands of people, it is validated that everyone has had these questions at least once in their career and many think about it often but do not know the steps to take to manage it successfully and professionally.

What is the definition of insanity?
“Doing the same thing over and over again expecting a different result.”

So what do you do?

Here are a few key tips you can take to enhance and maximize your career success:

1- Talk openly to your boss or a leader in your organization about what advancement opportunities do they see for you and share your career goals. How do these align?

2- Ask for honest feedback about your constraints and what to do to improve your positioning for advancement.

3- Ask for expected timing around advancement opportunities and set goals to achieve these steps.

4- “Continue to develop your ‘career capital’ which is the way to truly determine your value to the organization,” says Matt Roberts, President of Agile Austin.

By being clear and honest with your manager/leader about your expectations as well as setting a formal plan with SMART goals even if the company doesn’t have a formal succession plan you will set the right tone about what is important to you and where you want to be.

But remember you need to be open for honest feedback about what you could be good at vs something you may not. For ex: you may want to be a manager/leader but not everyone is cut out to be a leader.

Accepting the reality that you may not be cut out for who you truly want to be is a raw eye-opening experience. However, with a good career mentor who is invested in you as well as a sponsor inside your organization, you will be set for the greatest career success and personal satisfaction.

See open agile positions.

Blog

Courage and Craftsmanship

By: Agile Velocity | Mar 28, 2014 | Agile Technical Practices, Article

Last week I presented a workshop session called Courageous Software Development Through Craftsmanship (Slides) at Keep Austin Agile 2014 here in Austin. It was a great crowd both at the conference overall and in the session. A few people I talked to after the session said they couldn’t make it and wanted to learn a bit about the topic, so I thought I would write a blog post about it.

My intent was to create a conversation in the workshop and at the conference and I used LEGO brick sculpting as an activity to get smaller groups conversing about software built with/without courage. Overall I thought this went well and had a lot of good engagement and laughter from the attendees. Here is a synopsis of what we talked about:

Courage

Wikipedia defines courage this way:

Courage is the ability and willingness to confront fear, pain, danger, uncertainty, or intimidation.

If we explore many famous quotes about courage we get some insight in how to act courageously:

stand up and speak when needed
but be able to sit down and listen
be able to say no
face the truth
do the right thing
be virtuous when tested
do not leave what is right undone

And overall we see a link from courage to integrity. We can apply courage in many ways in our lives, but how does it relate to software development?

Courage in Software

Developing software products is not easy. It requires creativity, communication, collaboration, time management, and a whole lot of discipline all of which make it challenging. There are many situations where there is a need to stand up, be visible, say no, and do the right thing. Here are some challenging scenarios many of us have encountered:

Pressure to commit to completing something (when it may not be able to be done right)
Pressure to release when not ready
Pressure to adopt a process or tool that is counterproductive
Ability to hold a team member accountable when necessary

These are just a few of many. And there are many ways we can help individuals and thus a team act with courage. For many situations in software, Software Craftsmanship can help.

Software Craftsmanship

While there is still debate on whether creating software is an engineering discipline, a craft, art, science, or some combination, I feel that the motivations from the Software Craftsmanship movement can be applied to help.

For those of us in the Agile community, the Manifesto for Software Craftsmanship should be a familiar read. In it are the tenets of value, professionalism, and partnership that few would fundamentally disagree with. However, many rightfully are cautious of how these would be applied.

There is the potential for such a movement to be misused to push elitism, siloing, over design, etc. But if approached carefully the ideas around Craftsmanship that promote community, mentoring, skills development, pragmatism, pride in work, and attention to quality can be very powerful. I believe it is these ideas that can help. What practices or behaviors does software craftsmanship encourage?

Mentorship (often a bit formalized) and emphasis on learning and improvement
Deliberate practice, both solo and as part of a group (code katas, coding dojos, code retreats)
Strong technical practices (Test-Driven Development, pair programming, emergent design, continuous delivery, etc)
Community (local user groups, conferences, company communities of practice, craftsmanship swaps, etc)

There is an element of personal responsibility in all this for guiding one’s own skill growth and professional development. But there is also the notion of improving the knowledge, skill, and values of those around us that we collaborate with and on whom we depend.

Craftsmanship for Courage

I think not speaking out, not doing the right thing, not saying no when appropriate, not fully engaging, etc. can be attributed to a number of things, including some of the following:

An underdevelopment of skill or lack of practice
Lack of mentoring or knowledge transfer
Lack of true collaboration and accountability
The Imposter Syndrome or lack of confidence in one’s skill and knowledge

I think the notions of deliberate practice, community, mentoring, and focus on professionalism in the craftsmanship community are good tools to help people gain what they need to act courageously. Through increased knowledge, confidence in skill, and hopefully empathy for others who are learning and growing we should gain a better sense of what is possible (and what is not). This will allow us to be able to more confidently communicate and stand up for better ways to develop products that customers value and that we can be proud of.

Blog

Automated Testing for Legacy Software Products

By: Agile Velocity | Mar 20, 2014 | Agile Technical Practices, Article

Many times, we experiment with ideas and processes on new, or “greenfield”, projects. When starting something new, it is human nature to start with a clean slate and go from there. However, this is not always possible when automating testing. By nature, software features are first tested manually, most of the time followed by scripted test cases, and then the QA team starts thinking of ways to automate the testing. This just makes sense. I’ve heard it said “the definition of a legacy application is one that does not have any automated tests.”

So, you know you need to automate some of your testing. Maybe your team has acquired the skills (through new hires, classes, etc.) to begin writing automated test code. Where do you begin? Who should be involved? In talking with clients and other software testers in the Austin community, I get asked these questions a lot. Basically, how do we approach automating the testing legacy systems?

There is no single answer to this question. I believe what works best is to take the problem back to the team and start the discussion. The solution varies based on many factors such as the application under test, the skills of the team, and the value the team wants to gain from automating testing. There are several factors teams need to take into account when starting the endeavor of automated testing. The best automated test solutions involve tests at the unit, integration, and user levels. When starting out, ask when will the tests be executed, who will execute them, how frequently, and how much execution time will be tolerated before the team refactors the tests to improve performance? These are important things the team should agree upon from the beginning (not to say the decisions cannot be altered after learning more).

Start With Some Analysis

Do some analysis to decide where to start. Used tools such as Sonar to find out what classes are the most complex with the fewest unit tests? What files change the most frequently (therefore increasing risk of breakage)? What functional areas of the application are the most critical? Which functional areas are the easiest to automate? Any manual tests that are difficult for humans to execute, but easy for a computer? Are the manual tests boring or repetitive therefore causing possible human-error or oversight? How about tests requiring a lot of setup?

Take an Iterative Approach

Once you have a list of areas you want to automate, capture them as Technical Debt user stories, prioritize the list (as your Product Owner would do for features) based on effort and value. Keep in mind, the effort may vary greatly based on the tool or language chosen. As you probably know, there are many frameworks and tools for automating testing. Approach your evaluation of these as you would the software you build–in an iterative fashion. Try test tools that describe functionality with behavioral test scenarios, such as cucumber. If yours is a web application, evaluate javascript testing frameworks and tools which access the DOM and drive the user-interface, like Selenium. Evaluate the benefits of creating mock objects to use in automated tests with tools like mockito.

Share the Responsibility (and the benefit)

Every team needs to decide for themselves where to start and where the most value would be gained. Testers should collaborate with the developers in these decisions! They are software engineers and test automation is software, so why go it alone? Developers provide insight into making the automated test code simple, fast, reusable, and maintainable. Also, developers have much to gain from executing automated tests before they check code changes into version control, but the tests need to execute in their development environments and the feedback needs to be quick. Find a test framework that allows a subset of tests to be executed by developers to help them verify changes before commits. Then, extend the framework to get more coverage or perform end-to-end testing. Tests that are written solely by the testers and never understood or maintained by the other members of the team have a lesser value to the team at large. Find a way to automate tests that benefit the developers, testers, and even the product owner, and you will be happy you did.

References: Working Effectively with Legacy Code

Blog

Finding the Cure to “Yes”

By: Agile Velocity | Feb 03, 2014 | Article, Product Owner

In this article, we’ll explore the motivation for saying “yes”, understand the damage it can cause, and identify what it takes to be able to say “no”. Agile can help you build a culture focused on frequent delivery of value to customers. In the 12 Principles behind the Agile Manifesto, you’ll find it right at the top of their list.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

It’s a statement that’s easy to say, but hard for many organizations to emulate. They find themselves wondering how to assign value. Without understanding value, it’s difficult to make decisions. What should you build now? What should you build later? What shouldn’t you ever build?

Wouldn’t it just be easier to say “yes” to all of those incoming customer requests? This is a reality for many organizations whose customer sales drive development of their software products. But it doesn’t have to be, there’s a better way. The simplest solution is to just say “no”.

Why Do We Say “Yes”?

Why do we say yes to so many things? Why do we take on more than we can handle? Why do we make promises we can’t keep? Most of the time we feel that there’s no choice. It’s an all or nothing zero-sum game. But the damage that occurs when we say yes to something without delivering the goods is real and lasting. There are many reasons why we say “yes”. Here are the most frequent:

Fear of Damaging a Relationship
Customers have lots of ideas. Whether your customers are internal or external it’s important to keep them happy. No one wants to be responsible for damaging a customer relationship. The bigger the customer the more pressure we feel to deliver their requests. Likewise, demanding personalities also add pressure.

Fear of Not Getting the Work
One of the most common reasons we say yes is because we believe that if we don’t, then we won’t make a sale for new business (e.g. new customer or new business with an existing customer). There are many variations. See if any of these sound familiar:

The customer creates an RFP that seems to contain everything, including the “kitchen sink”, and solicits bids. You know there’s a lot of competition and you have no prior relationship with the customer. You’re worried that saying no to anything will cost you the deal so you say yes to all of it.
An organization within your company has allocated budget to finally start a project that’s been talked about for years. The reason it hadn’t been started before now was because it’s risky and costly so you assure them that you can do the work in a reasonable amount of time. In this case, “sale” can be translated into allocated budget.
You see an opportunity to provide some additional value to your customer (i.e. up sell), but they have some additional needs they would like met as part of the deal

Fear of Letting Down Management
Ever been given aggressive and improbable goals by your boss with a mandate to just “get it done”. Regardless of your relationship with your boss, you never want to let them down. Often when these situations arise, our response is heroic and we work longer hours and more days to try to get the job done.

Not Enough Knowledge
Sometimes we just don’t understand the work and effort well enough to say “no”, so we say “yes”, but what we really mean is “maybe”. In one instance, it may be the case of a team being approached with the work and remaining optimistic despite lacking the information needed to feel confident in their decision. In other cases, it could be that one person was responsible for estimating the effort for a large project that others will be responsible to deliver, without consulting them.

Is It Wrong to Say “Yes”?

Is it wrong to keep customer relationships intact? Is it wrong to get additional sales to help drive the business? Is it wrong take advantage of opportunities that you wouldn’t otherwise get? Is it wrong to work hard and push yourselves to achieve more? Is it wrong to take changes?

The short answer is “no”, but you have to be responsible as well. Saying “yes” to everything is like uncontrolled credit spending. It is short-sighted. You have all of these great opportunities you’ve purchased, but you find yourself in a growing amount of debt and eventually you’ll have to pay it off. You also might not like how you pay for it.

Consider the following potential side effects of “biting off more than you can chew”.

Cultural Impact

Increased tension among all of the people that work in your organization. Worry runs rampant and knowingly or unknowingly people feel less secure in their jobs.
Those in positions of authority and responsibility are trying to tightly control the situation down to every last detail. People that work with them feel micromanaged and a lack of trust.
Some buckle down and work with a sense of urgency. Others become disengaged and checked out. They become unhappy with the situation and feel no sense of control.

Business Impact

The time comes to explain to your customer why you cannot deliver what you promised. Understanding that based on your promises they made their own.
When you stop meeting your customer needs they start looking for other options. At a minimum, they will be more skeptical in future deals and your position to negotiate and sell will be compromised.

If these impacts resonate with you, you’re not alone. But don’t worry there’s another way.

The Path to “No”

Saying “no” sounds easy, but when and how do you do it. Here are some things to consider:
Trust with Customers – it’s hard to say “no” to a customer when you haven’t proven that you’re reliable; whether you just won a bid for work with a new customer or have had some performance issues with existing customers, it’s hard to say “no” unless they trust you
Transparency – information is important to you and your customers; even “bad” news can be helpful to customers when it’s provided early enough; be honest with what you know and what you don’t; expose risks that you have and what you’re doing about them; communicate regularly on progress and have something to show your customer
Frequency of Delivery – frequency of delivery can also build trust with customers; customers that have to wait for long periods of time will ask for more than they really need making it more difficult to say yes; deliver sooner and your customers may postpone some of their requests because they know you can respond quickly
Product Vision – it’s important to demonstrate to customers that you have ideas that can help them and those are priority; find something they will get excited about and they might be willing to wait for things they’ve already requested
User Community – creating a community across customers can help put their problems in perspective; it provides a forum where people feel heard and can share ideas with peers; it also allows people to share ideas and gain perspective; maybe your customers will find some common ground allowing you to say “yes” to a shared need (less) and “no” to many customized requests (more)

Conclusion

It’s no coincidence that many of the items that help you say “no” are related to Agile principles and sound product management. Companies that adopt these principles can build the confidence to say “no” and drive out fear in their organization. The effect can be powerful producing better products, stronger customer relationships, and a better environment for employees.