Agile Velocity, Author at Agile Velocity

Blog

The Role of the Agile Business Analyst

By: Agile Velocity | Mar 24, 2015 | Article, Product Owner

What is the role of the Agile Business Analyst? In this presentation to the Austin IIBA chapter, David Hawks, the CEO of Agile Velocity, talks about:

What are iterative requirements and how to do them
What are the roles of the product owner and how does the business analyst relate
How to create user stories
Incremental and iterative evolution of a story
Explanation of backlog physics

Business Analyst Roles:

BA as Product Owner

Share knowledge
Authority
Time

BA as ScrumMaster

Focus on helping the team
Supports the Product Owner
Becomes the master at Agile and Scrum

BA stays as BA

Supports the product owner
Supports the developers
Supports User and QA

For more information on Agile roles and org structures:

Organizational Alignment Will Make Or Break Your Agile Transformation

How To Find Your Next Product Owner

Blog

Building Shared Understanding: The Document Revolution in Product and Software Development

By: Agile Velocity | Mar 19, 2015 | Article, Lean

There is no doubt that the in-vogue tool today in product and software development is the “canvas”. Everywhere you look a new version appears touting new value and insights: Business Models, Opportunities Assessments, Organizational Visioning, and Sales Strategy. It seems like anything can be made into a canvas!

Canvases are the consequence of new innovative practices challenging the status quo of established organizations and social rules of how to run a business. It is a sign of the transition from traditional document driven product development to innovative and collaborative product development.

Organizations are challenged by what it means to get an agreement and ultimately shared understanding. In traditional product development organizations, shared understanding is created through charters, documents, lists, plans, charts and other formalized and signed documentation which tried to create a sense of tangible shared understanding.

“If we write it down, email it around, have a meeting and sign off, then we are in agreement!” Sound familiar?

No surprise that agreement is later fraught with misunderstandings and confusion about how the “agreement” translated into the real product itself. Let alone the lack of ability to deal with new information along the way that doesn’t fit into the signed off documentation, which quickly becomes not a document about shared understanding but a weapon in the war of who’s fault is it this time.

Today, it’s not about having a document proving an agreement. It’s about whether we actually have created a shared understanding of what we want to accomplish and how.

The collaborative act of building a canvas as a team (this is not an individual activity owned by one person) builds shared understanding leveraging ALL types of learning styles, (Visual, Audible, Reading/Writing, Kinesthetic), thereby maximizing collaboration, understanding, and innovation. Now, our “documents” are “vacation photos” representing the journey a team takes together with an idea.

Canvases have become a new standard replacing the traditional agreement document. A quick, easy and collaborative tool used with a team to create a solution together leaving them with some visual history of where they ended up and where they need to go next.

Basics of a Canvas

The idea is pretty simple; there is no magic to creating your own canvas. Take an old approach to find agreement (document passed around) and find a way to build it visually. Check out a canvas below for a way to lay it out. Visually solve the problem together as a team on a white board (can fit on a picture or a smaller one-page document later). Use it as a team DURING a meeting to get closure on circling discussions. Come to agreements and action visually–organized in a visual layout (not a list). Leverage all four types of engagement. (Visual, Audio, Reading/Writing, Kinesthetic)

Stop trying to collaborate with only words. Visualize it. Canvases can help meet the challenge of documentation that fits the fast paced and innovative product environments of today.

Here are a few of the original and most popular ones that started the movement.

http://www.businessmodelgeneration.com/downloads/business_model_canvas_poster.pdf

http://www.businessmodelgeneration.com/downloads/value_proposition_canvas.pdf

https://leanstack.com/LeanCanvas.pdf

Join me in the upcoming Lean Product Discovery workshop.

Blog

Accelerate Learning and Overcome the 6 Traps of Agile

By: Agile Velocity | Mar 10, 2015 | Article

At ProductCamp Austin, David Hawks presented Accelerating Learning and Overcoming the 6 Traps of Agile.

Accelerated learning is the key to unlocking the true potential of Agile. Often organizations implement the process aspects of agile/scrum but fail to find the key to unlocking its true potential. This presentation explores six traps agile teams fall into which prevent learning and how to overcome them. A potentially shippable product increment is the key and how to break work down, swarm, limit WIP, and get to done are imperatives. By accelerating learning we believe most organizations can deliver double the value in half the time.

Click here for the slide deck.

Blog

Introduction to Agile for Product Managers

By: Agile Velocity | | Article, Product Owner

David Hawks presented Introduction to Agile for Product Managers at ProductCamp Austin.

Agile for Product Managers presentation:

What is Agile
How it compares to traditional waterfall development
Advantages of Agile for increased visibility and shortened feedback loops
Introduction to Scrum
Product Owner role
Backlog Physics
Story Funnel

Product Owner Responsibilities

Drives Product Success
Creates the Product Vision
Creates and Maintains the Product Backlog
Collaborates with the team
Collaborates with Stakeholders
Participates in Sprint Meetings

Characteristics Required of a PO

Knowlege
Authority
Time

Click here to see the complete slide deck for an Intro to Agile for Product Managers.

More information about Agile and Product Owners:

How to find your next product owner

Accelerate Learning and the 6 Traps of Agile

Blog

5 Good Habits of High-Quality Scrum Teams

By: Agile Velocity | Mar 05, 2015 | Article, Scrum

Kent Beck said it best: “I’m not a great programmer, I’m a pretty good programmer with great habits.” What are some of these habits which help product development go from good to great? Beyond test-driven development and SOLID design principles, there are five good habits that will improve the overall quality of your software and build high-quality scrum teams. These are not abstract concepts, but tactical process changes I’ve seen work wonders on teams I’ve been on!

1 – Technical Implementation Discussion on Every User Story

Most teams these days have access to a physical or virtual whiteboard. Use it! Get the entire team (don’t forget QA) together and sketch out the application areas that will need to be changed to implement the feature described in the User Story. This gives everyone on the team an opportunity to ask questions and voice concerns until you reach a common understanding. Heck, some team members may just learn something about the software architecture from these discussions! Not to mention, it is a lot easier to erase a line or change a design on a whiteboard than it is rewriting code.

2 – Test Planning Discussion on Every User Story

Once the implementation is understood by all, have a discussion on how the feature will be tested. Jot down a list of areas you intend to write unit tests around. What tests can be covered by an automated integration test? Talking about testing will get the brain juices flowing. The team will naturally think of the impact these changes will have on other areas of the application, so this good habit can prevent “oops, I forgot to update that report when we added such and such!” I have found the more everyone understands about the implementation, the better testers they become.

3 – Effective Tasking

For software development teams, capturing their work in tasks is not easy to do. However, teams with tasks on their Scrum Boards which really describe the work, tend to implement features faster. I think this is because there has to be some implementation/testing discussions in order to create the tasks. The level of detail included in tasks varies from team to team, but eventually, the team will decide what is “just enough” detail needed to provide clarity and visibility. People do better when they can focus on small chunks of work. Clear tasks that are small enough or isolated to particular areas of the application, also encourage collaboration. If you find you are creating the same tasks on every User Story (i.e “Implement the feature”), then this habit might be something to challenge yourself to do.

4 – Swarming on Stories

To me, it is a simple concept, but one that new Agile teams rarely make a habit. That is, the team working together on stories in priority order until they complete all tasks. This does not mean a team cannot work on more than one story at a time, rather, the team is aware of what needs to happen to finish a story. Working to finish a story takes priority over starting work on a new story or one that is far from being finished. Truly iterative development involves completing User Stories throughout the Sprint. If you are waiting to test all of your story work on the last day of the Sprint, try swarming. Focus on finishing, not starting.

5 – Product Owner Sign-off

The Sprint Review demo meeting should not be the first time the Product Owner sees the feature! It is important to get PO feedback early and often as development proceeds through the Sprint. This is why my last good habit is doing a PO Sign-off of every User Story. We simply create a task on our Scrum Board to track it. When we are ready to show the new feature to the Product Owner, we use an integrated environment which has been built using the Continuous Integration server (not the developer’s local environment). Anyone on the development team can lead the sign-off demo and any other team member can listen in. The objective is to get feedback from the PO on whether the Acceptance Criteria have been met. The sign-off process typically includes these actions:

Read through each Acceptance Criteria and demonstrate it
Updates to the User Story/Acceptance Criteria if they seem unclear
Discuss what was tested beyond making sure we met the Acc Criteria
Discuss any automated test coverage
Allow the PO to interact with the user interface

At first, you might find you will attempt to get PO Sign-off on the the last day of the Sprint and fail to get sign-off. This causes the team to rush making last-minute changes. I know I don’t like working under pressure like that. With some good habits, your team will learn iterative development with PO Sign-off well before the end of the Sprint.

Does your team need help adapting and improving? Contact us today about our Agile Assessment services, where we can help you identify and implement the kind of improvements you want to make.

Blog

The New Focus of Agile Product Development: An Intro to Product Discovery

By: Agile Velocity | Feb 24, 2015 | Article, Product Owner

It’s been over 10 years since the official Agile movement startedㅡa time when companies were focused on projects, deadlines, and budgets. Agile approaches shifted thinking from large, single delivery linear projects to small incremental, continuously delivered features. This shift demanded changes in thinking around many parts of the organization.

Managing the complex environment of delivering software forced new business structures that allowed these environments to thrive. Examples include continuous integration, one button releases, test automation and most importantly, the breakdown of departmental silos and the push for collocated teams comprised of people needed to deliver the product.

Agile Product Development – Feature Focused

The shift from project to feature focus required an organization to fundamentally accept they could NOT know what was needed to deliver at the end of the project. In order to achieve desired objectives, companies had to set themselves up to deliver product differently.

We have seen great advances and success of businesses making the agile shift, but with time, a new complexity shift has followed. The feature focus brought quality, efficiency, collaboration and quick output of new features but often fell short in creating the real outcomes and business impacts companies hoped to achieve. Delivering features faster didn’t always guarantee happier customers or a stronger product.

Enter the shift from Feature focus to Discovery focus.

Agile Product Development – Discovery Focused

Today, product minded businesses with agile teams can stop wasting time checking on schedule and output and spend that valuable energy on the impact their product makes on their customers. Teams successfully making this shift are quickly realizing the value of setting themselves up to not only build the product right but also build the right product.

To build the right product, teams have to take one step further back. Instead of starting with “what should we build next?,” they lead with “what are our customers experiencing?”

From there, teams focus on discovering more about their customers, which leads to interesting problems they could not have imagined, but used their expertise to solve.

The shift from feature to discovery focus requires an organization to fundamentally accept that they did NOT know what a customer wants or even possibly who their customer or market is. Therefore, they set themselves up differently to discover who their customer is and what problem they can solve. Then you can start building “the right product”.

So what is Product Discovery specifically?

That is still getting worked out since it is emerging. Presently, it is often a combination of practices adopted from:

Lean Startup
Design Thinking
Systems Thinking
Customer Development
Experiment Design
Visual Thinking
Traction
Agile and a whole lot more.

These practices are becoming an amazing toolset that advance companies’ abilities to really delight their customers.

It isn’t a framework and shouldn’t become one, but we are slowly gaining more experience with the best approaches and techniques to support this new way of working. Companies making the shift have to be prepared to accept a new level of complexity that comes with not deciding a firm upfront direction or relying on the business to make feature decisions.

These two necessary parts of Discovery and Delivery require different approaches and mindsets. They may feel like they are at odds when being used in one team, especially since you can’t plan a sprint of discovery and there aren’t discovery stories that you can size. We are discovering what to build! How could you size that?! Balancing Discovery and Delivery is how to create the greatest value.

Those willing to adapt once more will accelerate their agile delivery and create the true customer outcomes and increase desired business impacts.

Over the next few weeks, I’ll share a few approaches and techniques that might help you get started.

Please comment and ask questions below or come to the upcoming workshop.

About the Author

Erin Beierwaltes counts herself lucky to have found a passion in the agile and organizational cultural movement.

Through a mix of system theories, cultural principles, and business practices, Erin partners with businesses to find the right balance of product, process, and people, to create a responsive and adaptive learning organization.

Erin has been working on organizational development for over 10 years, working with established Product companies and startups, to adopt “just enough” formal approaches to support high paced growth and change. She believes strongly in addressing the combination of product discovery (figuring out what to build), process (how to set up processes to build high-quality products quickly), and people (how to create a great culture) to reach organizational level agility.

Blog

High Performing Distributed Agile Teams

By: Agile Velocity | Feb 18, 2015 | Article, Team

Mark Spitzer, Agile Coach, presented at the San Antonio Agilistas meeting. In this presentation, he addressed common challenges for distributed agile teams. Common scenarios are covered along with practical suggestions that have been successful for many organizations. This presentation debunked the agile myth that it can’t work when an organization has distributed teams.

Once upon a time, there was a team of individuals who interacted daily. They found the most efficient and effective method of conveying information is face-to-face conversation. They lived together in one place and they called it pangea. Everyone was happy. Then one day they noticed everything had changed. Everyone was LOST. Agile clearly won’t work here. This is the end of Agile. Why do companies have distributed teams?

Takeaways:

Create a virtual team room to foster communication through the day
Investment in travel opens communication channels
Host Scrum of Scrums using video to address inter-team dependencies and alignment
Keeping teams co-located within an office helps team cohesion
Invest in network infrastructure to support richer communications
Online collaborative tools make retrospectives and planning more effective and fun
When most of the team is remote, make periodic trips to see them

View the slide deck by clicking on the image below.

Blog

Agile Coaching Variations

By: Agile Velocity | Jan 28, 2015 | Agile Coaching, Article

What is an Agile Coach?

Teams that are adopting or facing challenges with Agile development often turn to an Agile Coach for help. Agile Coaches are usually someone more experienced with Agile process and techniques who can guide the team through rough patches until they can find their own way. Like a sports coach, an Agile Coach may show inexperienced teams how Agile practices work, or may do more listening and asking questions to help the team improve. Traditionally, however, Agile Coaches spend all of their time focused on the coaching role and are not a team member. An alternative variation, the Player-Coach, addresses this limitation.

Player-Coach as an alternative

The Agile Player-Coach can pick up regular development tasks like any other team member, but also spends time coaching the team and others on improving Agile practices. Being “on the team” helps to foster trust from the other team members. Also, a Player-Coach is better positioned to help address problems of Architecture, Design, and Implementation. Further, because a Player-Coach works more directly with the rest of the team, there is more ability to discover problems that fail to surface from briefer observation and questioning.

Quick Aside

Before I continue, I must detour for a quick discussion around names. We have struggled to find the right name for the role of Agile Player-Coach. Alternatives include Embedded Coach, Technical Team Coach, and Embedded Player-Coach. Ideally, the name should convey that the role includes coaching on Agile practices, but also that the person contributes to the workload of the team and is a team member with technical skills to help deliver working software, even if only for a few months. For now, I will stick with Player-Coach, but I welcome input on a better name.

Tradeoffs

To be sure, the Player-Coach role can be difficult. It is challenging to jump in and be productive as a team member while also balancing workloads to find time to coach. A more traditional Agile Coach tends to work with multiple teams, with different roles, and across the organization and is more able to suggest changes to “optimize the whole“, while a Player-Coach will be more focused on team related optimizations.

However, a Player-Coach can bring technical expertise the team does not have, which can be leveraged while they are there. This means the Player-Coach can implement technical solutions that will improve the team’s efficiency (things like DB change management or centralized logging), but which are not really Agile practices. Of course, the Player-Coach should also mentor other team members through code reviews and mentoring and generally “leading by example”.

Which is right for you?

Each Team is different…with their own project challenges. That means that how you coach a team depends on what they need from you. — Agile Coaching, Rachel Davies and Liz Sedley

The choice between a more traditional Agile Coach and a Player-Coach depends on the situation. Each brings a unique set of strengths and abilities. In general, a more experienced and mature development team might not benefit from a Player-Coach as much as a less experienced team. Also, a more traditional Agile Coach can focus solely on helping improve a group’s Agile practices. However, a Player-Coach is a good alternative when a team needs help with both Agile and technical problems.

Contact Us

Most of the teams Agile Velocity works with have some experience with an agile framework. We work with a team to evaluate what they’re doing, how they’re doing it and identify where they can improve. From there we serve as coaches/guides embedded with the teams we’re helping. Our Technical Player-Coaches accelerate the team’s journey to high performance.

We’re interested in helping your team adapt and improve. Contact us today and talk to a Player-Coach about what kind of improvements you want to make!

Blog

Virtualization Makes Me a Better Developer

By: Agile Velocity | Jan 19, 2015 | Article, ScrumMaster, Technical Practices

In the past, developers either had only the choice between multiple machines or sharing development environments. In the first instance, this is an expensive solution and in the second, lots of developers sharing a single environment leads to contention issues. To further exacerbate this problem, the trend is towards application deployments that involve multiple servers.

Luckily, a solution has presented itself in the form of virtualization. Now, all of the systems needed for running a deployed application can be hosted on my laptop using Virtual Machines (VMs). I have been using Oracle’s VirtualBox on my MacBook Pro (16GB RAM), but the same applies for any virtualization technology you choose. By using a VM (or several), I am able to isolate configuration changes from my development system to help make my test environment as production like as possible.

Not Just Linux

Also, I am able to easily switch out dev environments, so I can test on multiple target OSs, all while using the same underlying hardware. “That’s great”, you say, “but what about Windows and its associated licenses?”. Well, Microsoft has made available VM images for a full spectrum of host OSs, VM software platforms, and a range of IE and Windows flavors. These Windows images have a 90-day time limit from when you first start using them, but, the same VM image file can be used to make new Virtual Machines and the 90-day time limit starts over. See Ray Bango’s Blog for more on this.

Automate Them

The next step in making the best use of VMs is to make the process of spinning them up and deploying to them automated. Vagrant can really help here. I’ve used Vagrant to automate the whole process of provisioning, deploying, and even testing an application and the benefits were enormous. Note using Vagrant with a Windows VM can be a bit more difficult. You might need to create your own Vagrant Box using a tool like Packer. See the article Creating Windows BaseBoxes and this Packer Windows GitHub repo for pointers on making Windows work with Packer and Vagrant.

You can also take things a step further and automate the deployment of your app with tools like Chef or Puppet, which you should probably be doing anyway.

Costs

You might think by using VMs I have to give up some performance, but that is not always the case. For example, my current application development requires an Oracle DB. I run this on a Linux VM. I have found that it is much easier and faster to backup and restore snapshots of the entire VM in VirtualBox than to use Oracle’s tools to backup and restore the DB.

Another cost associated with using VMs is memory. This is unavoidable. But, with memory prices at the point that 16GB is under $200, this is a price I am more than willing to pay.

VMs are not just for the Cloud

Because virtualization has been used mostly to support IT and DevOps activities, developers may be unaware of their capabilities or how easily they can be used, but with a little effort, the payoff can be dramatic. Also, I have found deploying to locally hosted VMs to be a much faster process when compared with deploying to Cloud VMs. In conclusion, by deploying and developing using a Virtual tier, I am able to get more accurate and more rapid feedback when compared to using a shared Dev or QA tier, and that makes me a much better developer.

Blog

An Effective Approach to Agile Development Team Challenges

By: Agile Velocity | Dec 15, 2014 | Agile Coaching, Article, Team

A Team’s Agile Development Journey

What typically happens when a software team adopts agile values and principles and implements a framework (such as Scrum)? Normally, after some initial learning, an early positive impact is common along with a feeling of progress. But the team soon encounters new challenges as they realize their journey has only begun. They must now take ownership of their improvement.

Initial Success

A team with the desire and understanding to achieve agility is a wonderful thing to see. The collaboration, focus on customer/purpose, and sense of progress is empowering for teams. The feedback and building of trust within different groups or roles that may have been missing before is also inspiring. But new challenges start to emerge.

New Challenges Emerge

The iterative nature of agile frameworks is a big change for many. They are not familiar with the concept of releasing working software in short cycles. Experienced technical team members find their practices are no longer as effective. Their testing, whether manual or automated, might take too long or lack feedback. They may struggle to collaborate with the Product Owner to agree on how they will know when they are done.

The Team Adapts

Faced with new challenges, agile teams have many ways to improve. They have Retrospectives or Operations Reviews to inspect and adapt their behaviors and practices. Through this process, they can look at data and experiment with changes that improve product delivery. But how do they know what to look for and what to try? What are proven, good practices that can be leveraged?

The amount of resources available today is impressive. Books, blogs, and videos are plentiful. But the advice contained within has to be found, consumed, digested, disseminated, and attempted. When something is tried, the team needs to look at the results, see what was learned, and iterate. This takes time. For many teams the concept of owning and taking responsibility for their own improvement is empowering, but new. Even learning this process takes time.

Using a Technical Player-Coach

A typical Agile Coach helps a team get more value out of their efforts to improve agility. These Coaches draw from past experience delivering software and mentoring teams. As with general Agile Coaches, they help the team through mentoring, questioning, facilitating, and other forms of guidance. Coaches also add knowledge and insight where they can accelerate learning. But the impact they make is limited by the amount of time and depth of knowledge they have with the team.

An embedded team member has the opportunity to make a significant impact participating in the full software delivery process. In this role, she becomes a Player-Coach who develops direct experience with the team’s delivery challenges. From this vantage point, she can lead by example in helping the team adapt and improve. She will not only do feature work for the team, but also use techniques like pair programming and code reviews, retrospectives, and communities of practice to mentor and coach the team from within. Her ultimate goal is leaving the team with the ability to continuously improve.

This Technical Player-Coach(TPC) helps teams with all aspects of Agile Software Development. Often this involves technical practices such as testing, refactoring, Test-Driven Development (TDD), Emergent Design, Devops, Continuous Delivery. Such practices are critical to realizing overall agility but are not normally taught in Scrum or other Agile training courses. The Player-Coach also helps with common agile practices from a team member’s perspective such as breaking down stories, collaborating on acceptance criteria, and providing feedback to the rest of the organization.

It takes time to build trust and work effectively with teams. The Player-Coach is highly impactful as a participating team member with skin in the game.

We will follow this with a series of posts highlighting specific scenarios showing how an embedded Player-Coach is a valuable resource for teams.

Contact Us

We’re interested in helping your team adapt and improve. Contact us today and talk to a Player-Coach about what kind of improvements you want to make!