Live Online Summer BOGO!

written by: Melissa Monroe on June 11th, 2015

Buy one class scheduled in July or August and receive a second seat in the same class for free!

BOGO Summer!

Furthering your career doesn’t have to mean giving up your vacation this summer.

That’s why we’re offering summer BOGO for live online sessions! Register with code BOGO2015 for one seat in a July or August live online training session and get a second seat in the same session free.

The convenience and flexibility of our live online training helps you and your team gain the skills and knowledge you need without having to give up the vacation you want.

Find the right course path for you. Where will this summer take you?

 

*Offer cannot be combined with any other offers. The offer is valid between July 1 and August 31. First registration must be made at full price. Free seat is for the same session. Use code BOGO2015 at checkout to receive discount. Some course exclusions may apply. These terms and conditions are subject to change at any time.

 

Share

3 Levels of Leadership for Agile Transformations

written by: Melody Yale on August 26th, 2015

businessagilitySelf-organizing teams rely on several levels of leadership in order to be successful. Business Agility is not just a “nice to have”. It’s a competitive advantage for leaders and organizations. Being able to adapt quickly in order to respond to new market problems is what separates the winners from the losers. But actually transforming an organization from a waterfall methodology to an Agile delivery model is tremendously hard. It can be a thankless and lonely job. There are hurdles to overcome and people will push back. Agile transformations can fail because leaders do not have the emotional wherewithal to finish the job.

Why is it so hard?

Agile development requires change in culture, people and process. When you are transforming at the organization scale, you are removing the stability that people have come to know and love. You are changing their roles and responsibilities and you are changing the process by which their success is measured.

Click to continue »

Share

How Agile Development Increases the Team Happiness Factor

written by: Melody Yale on August 24th, 2015

burnout

I worked with a company that used the acronym- WOW. Sounds like it should be fun, but it meant “work on weekends”. Unfortunately this happened more often than not. Teams would scurry around to complete work in the last hours before the release because inevitably software developers were over-committed. The problem wasn’t necessarily with the software development teams, yet they were the ones that suffered. The whole process was broken including the fact that scope was inflexible and the date was set. And of course the mind-set was to deliver everything that was committed to on the date that was set- a year ago. This results in lots of tension between the business, project management and software development. It also results in a “just get it done” attitude. Well, that’s no fun.

In Agile development we value working at a sustainable pace. Most people value work/life balance as an important aspect of their job. When people are happy with their jobs, they are more likely to be productive and stay with the company.  According to a recent survey by Staples, job burnout is a major reason why people begin to job hunt. It’s no secret that turnover is costly to an organization. Not just because you have to recruit and hire someone to replace the person who left, but because the person who leaves takes with them an enormous amount of tribal knowledge that is valuable to our projects.

As servant leaders we have an impact on the work/life balance of our teammates. As ScrumMasters we can coach members of the team to not take on more work than our stated capacity. We can discourage a culture where we brag about working 70 hours a week or regularly do not take lunch breaks. ScrumMasters can coach team members on how to manage their schedule so that they are able to maintain a sustainable pace. They should have some time for lunch or take a brain-break during the day.  As Product Owners we can respect the average velocity of the team and plan for it- so we can set expectations for what is actually achievable. We should respect each team member’s time off and be mindful to not request more than necessary.

A sustainable pace goes hand in hand with a fun workplace. We should make it a priority to have fun with our teams, as that simple act of bonding makes us more empathetic to individual needs. Also because a fun workplace is just a better place to be. You rarely hear someone leave a job because they were having way too much fun. And while we’re trying to recruit the best and the brightest, we must consider what job aspects matter to the new workforce.

Share

Web Seminar Recap: Lean Analytics Overview

written by: Admin on August 21st, 2015

Lean Analytics supports Lean Startup by measuring and analyzing data as you progress, with a focus on data-driven decisions.  Lean Analytics works in conjunction with Lean Startup, which challenges traditional approaches and shows how traditional ways of measuring a project does not work in a startup situation.

On August 21, 2015, Robert Tyson presented a 1-hour web seminar on Lean Analytics and its role in Lean Startup. He discussed topics such as:

• Innovation Accounting
• Lean Analytics Stages
• Vanity vs. Actionable Metrics
• The One Metric That Matters

Missed this web seminar? Catch up by downloading the presentation slides and recording here.

Share

The Minimum Viable Product

written by: Robert Tyson on August 18th, 2015

Leveraging the Minimum Viable Product in new product development

mvpOne of the practices used in Lean Startup is the Minimum Viable Product or MVP. The MVP is the most basic version of a product. It is aimed at extracting feedback from customers, or potential customers, based on specific product experiments. The idea is to look for evidence of demand before building a complete, functioning product.

For the entrepreneur, the MVP is a valuable tool to gain insight into a new product or a new growth market. Leveraging the Lean Startup Build-Measure-Learn cycle, a properly executed MVP drives product development and provides valuable data for pivot or persevere decisions.

The MVP should be viewed as a process, not a product. Building rapid iterations of the MVP, measuring results, and learning from those experiments requires discipline – it requires a process to be successful.

The MVP goal is to execute the fastest turn of the Build-Measure-Learn cycle as possible, with minimum effort, and minimum development. Doing this allows the entrepreneur to start learning as quickly, and as frequently, as possible.

When designing an MVP, each version should have just enough features to test out the hypothesis. Any work performed beyond that goal is a waste. MVPs are used to test product design or technical questions, test fundamental hypotheses, and extract feedback from customers. Through the MVP, the entrepreneur learns the features the customer really wants.

A frequent mistake is to overestimate the needs for the MVP. If there is any doubt, then simplify. Having too many features can make the analysis of the results difficult. How do you know which change actually drives behavior? Too many features may also create a premature maintenance overhead as you try to maintain what you have deployed. Keep the features simple and targeted. Any features beyond that is a waste of resources.

An MVP helps to clarify the conflict between what customers say versus the actions they actually take. The customers’ actions when using the MVP may contradict what the customer stated as their top priorities. Be sure to include methods to capture metrics in the MVP.

The MVP may also end up in bad news. It may prove that a basic hypothesis does not hold up. This information is critical in decisions to persevere on a product’s current path or pivot, and find a new hypothesis. It requires courage to put your assumptions to this sort of test. However, finding out early prevents wasting resources in developing the wrong product and, often more importantly, prevents the lapse of precious time.

An MVP is not always software. The new innovative item may be a service offering or retail product. Regardless, ideas need testing before building massive amounts of infrsatructure. Simple tests often suffice. Published examples include:

  • Groupon – initial MVP was email, PDF files, and the bar in their building
  • Food on the Table – personally delivered food and created recipes with a single customer
  • Aardvark – manually answered searches

The Food on the Table MVP is an example of a “concierge MVP”. In this type of MVP the initial customers are given special treatment – sometimes unbelievable treatment! In the Food on the Table example, there was initially just one customer. The entrepreneur personally went to the customer’s house to develop recipes and deliver groceries. If you test your hypothesis using concierge treatment and the results do not look promising, then you need to re-think your strategy!

The Aardvark MVP is an example of a “Wizard of Oz MVP”. The hypothesis was tested by manually executing “behind the curtain”.

Neither the Concierge MVP nor the Wizard of Oz MVP is a viable, sustainable approach as a long-term solution. The key aspect is that the entrepreneur learns valuable lessons that would be difficult to duplicate by other means. Validate the leap-of-faith assumptions early before the significant investment of time and money.

Often considered low quality, software MVPs may challenge the developers’ traditional values around quality. These MVPs are designed to perform specific experiments, not produce a polished final product. The target customers are often early adopters who see the potential for breakthrough products. They are more forgiving of mistakes and suspicious of anything that appears as too “polished”.

The Minimum Viable Product is an entrepreneur’s tool for rapidly gathering customer feedback about a proposed product or service. The MVP is used to validate initial assumptions and to guide product development. It provides valuable information about strategies and when a pivot may be in order. When developing an MVP, be clear about what you want to learn and how you will measure it.

———————————————–

Robert Tyson (PSM, ITIL) is a veteran IT professional with over 35 years’ experience in both domestic and international environments. He is currently an Agile Coach and Instructor with Agile Pi.

Share

What are Your Software Development Guiding Principles?

written by: Melody Yale on August 17th, 2015

Software development has changed a lot since the 1990′s. Project Managers used to spend a lot of time planning, designing and estimating only to find that six months into a project the inevitable happened- the requirements changed. Spending time on more documentation led to failed projects and frustrated Project Managers. There had to be a better way!

Agile development principles were built upon years of best practices. We often spend a lot of time stressing the importance of a few development principles when we coach teams transitioning to an Agile delivery model. Let’s explore how a few of the principles have changed our processes.custom_software_development1

Instead of the frustrating scenario above, Agile development welcomes changing requirements, even late in development. We’re able to accommodate this because the product owner reserves the right to prioritize the backlog frequently. If a customer has an emerging requirement that is the most valuable of all requirements, then the product owner is able to schedule it appropriately. This creates the perception of faster innovation and is truly a competitive advantage for you and your customer.

Working software is the primary measure of progress. By working software we mean that we will produce a shippable increment of software each sprint. In order for something to be shippable, it has to meet some criteria set forth by the team. The definition of done is the checklist of that criteria. What does done mean? Done is an ambiguous term and inconsistencies are often uncovered in sprint review. Are you done with programming? Are you done with QA? Have you documented this new feature?

When we’re delivering working software frequently we need to make sure we agree on what done means for three reasons. First, we don’t want to kick un-done work down the road by rolling over tasks to the next sprint. Second, if we’re not completing the work in our sprints, then we cannot count the time toward our velocity. Velocity is important because it’s used to estimate how much work can be completed in a sprint and helps product owners create a forecast for the release. Third, the definition of done is an agreement of the team to ensure a consistent level of quality for each shippable increment.

Speaking of quality, being consistent with a high level of quality each sprint is important. Have you ever worked on a software product that had a ton of technical debt? Customers can’t appreciate the good work you’re doing if they can’t get past the bugs, performance problems, and bad design. Bad quality is expensive. Fixing bugs is disruptive and expensive not just for the software development team, but for the customers who use the software and who may have to spend their time updating the software. Since satisfying customers is our highest priority, Agile development best practices recommend quality over quantity for this reason. Quality is controlled by a heavy emphasis on a test driven development approach and automated tests that run at regular intervals throughout the development process.

Now with globally dispersed teams and the internet of things creating greater demand for software, we can’t afford not to be Agile. The Agile principles pave the way for better software development. Other than the Agile principles what guiding principles do you need for your Agile development delivery model?

For a full list of all 12 Agile principles you can access them here.

Share

The Lean Intrapreneur

written by: Robert Tyson on August 12th, 2015

Understanding and applying Lean Startup principles from within an organization

Entering StartupEverywhere you look  you see entrepreneurs. You can even find them inside rigid corporate organizations, they are referred to as “intrapreneurs”. These internal entrepreneurs face special challenges trying to innovate within large companies. The structure that runs the company so well operationally is not so well equipped to handle the risks, uncertainty, and unpredictable nature of a startup.

A “startup” can take on many different faces. It includes new product and new company startups and everyone trying to produce the next big thing. However, it also includes initiatives that are internal to companies. Think of Lean Startup as a framework to help you with transformational or change initiatives – disruptive changes.

An intrapreneur is a person within the corporation who has the responsibility for turning an idea into a sustainable finished product, or new service, or new way of working. Efforts within an organization often have more of a focus on “impact’ rather than “revenue”.

Click to continue »

Share

Web Seminar Recap: Lean Startup Overview

written by: Admin on August 12th, 2015

For new product development, Lean Startup provides a fresh approach and proven framework for creating new products. Lean Startup challenges traditional approaches and shows how traditional ways of measuring a project does not work in a startup situation.

On August 11th, ASPE Agile Coach, Robert Tyson, presented a free one-hour webinar on Lean Startup. Participants gained an overall understanding of the background, principles, and benefits of Lean Startup along with how it differs from traditional new product development.

Some of the topics Robert covered in this seminar included:
• What is Lean Startup?
• How Lean Startup differs from traditional approaches
• Lean Startup Principles
• Build-Measure-Learn Loop
• Pivot or Persevere

Missed this seminar? Catch up by downloading the slides and recording here.

Share