Skip to content

Companies

Scaling Agile Your Way: Agile Scaling Aspects and Context Matter Greatly (Part 1 of 4)

Agile Management Blog - VersionOne - Mon, 09/08/2014 - 17:16

Consider these five very different types of organizations:

1.  An organization with fairly hierarchical management structure, traditional Project/Program Management Office (PMO) trying to transition from traditional waterfall development to agile development.  Some teams have just a few months of experience with Scrum, and perhaps worked with few XP or Lean practices.  Budgets are done on an annual basis.  Senior management pays lip service to agile transformation and treats agile as a silver bullet.

2.  A government contractor is used to delivering projects on a fixed-price basis.  The government agency has now asked the contractor to use agile methods for large-scale agile projects.

3.  The CIO and CEO of an enterprise are strongly committed to agile-lean development and have given a top-down marching order to follow agile methods.  All teams have been ordered to follow a two-week iteration cadence, while members of some teams come from an offshore outsourcing vendor.

4.  A company has found that their main competitor will be Amazon.com.  The release cycle for most of its IT projects is six months, and they know that unless they drastically reduce this, Chapter 11 is not far away.

5.  A startup company realized that unless they validate their assumptions about who the real customers are, and what the real needs of real users are, they have no viable business.  They decide to follow the Lean Startup method by rapidly developing a series of Minimum Viable Products (MVPs) in rapid succession.  Even after the first release of the product, the company must stay ahead of competition and deal with rapid changes in market conditions.

With the vast diversity of organizations and their projects, a cookie-cutter approach (or prescriptive recipe for all types of projects and situations) will not work.  Each agile project developing a product or solution has a unique context: assumptions, situation, team members and their experience and skill sets, organizational structure, management’s understanding and support, maturity of practices, challenges, culture, etc.

No_to_straight_jacket_agile

Many agile development teams now have some experience of team-level agile practices using Scrum, XP, Lean, Kanban or Scrumban frameworks.  Some of these organizations have experience with Scrum of Scrums (that is, two to as many as nine Scrum teams working together on a product or solution). These teams and their organizations are now setting their horizons to undertake large-scale agile projects where several (10 to 1,000) teams must collaborate to implement the common vision of a product or a solution.

In the last few years, there has been increasing interest in scaling agile-lean methods beyond individual teams or Scrum of Scrums to programs and portfolios of teams, as well as being able to compose new applications by stitching together a set of services developed by independent teams.  The recent Agile 2014 conference had numerous presentations on the topic of scaling agile.  I attended as many of them as my schedule allowed, and caught much of the rest as recorded sessions.

Many of these sessions raised the issue of ‘which scaling agile framework is best?’ I came away thinking that every large-scale agile project creates a unique situation. To tackle this question, there are really two broad approaches you can take to select the right agile-lean process for your project:

APPROACH #1: Select a well-known, scalable agile framework listed below.

A. Scaled Agile® Framework (SAFe™) by Dean Leffingwell and his associates at Scaled Agile Inc.
B. Large-Scale Scrum (LeSS) by Larman and Vodde
C. Disciplined Agile Delivery (DAD) and Agility at Scale by Scott Ambler and his associates
D. Matrix of Services (MAXOS) by Andy Singleton

If necessary, extend or adapt or customize the framework to suit your unique needs. As you gain experience, inspect and adapt for ongoing refinements and further customization. “Scaling Agile Your Way” does not mean that each new large-scale agile project must develop its own agile processes from scratch.

APPROACH #2:  Develop a customized approach from scratch.

Or, if your project has truly unique needs that cannot be satisfied by any available framework (such as SAFe, LeSS, DAD, MAXOS) even after customization of the framework, you may need to develop a set of new processes from scratch customized to your unique needs, and then sustain and maintain those processes.

In many organizations, not many in-house people have this kind of expertise that would actually work.  Moreover, this approach would be expensive and may not be cost-effective.  As such, this approach to large-scale agile projects should not be undertaken on the ground of ideological purity, but should be based on solid business reasons.

It is important to state what “Scaling Agile Your Way” does not mean.  It does not mean that each team in a program is free to choose and optimize its own agile method, practices, cadence, release duration, metric and reports, etc., without any coordination with and consideration of other teams in the program.  If this were done, although each team may end up optimizing its own way, that may ignore what is good for the higher level program.  Similarly, optimizing at the program level without any regard to the higher portfolio or enterprise level is not “Scaling Agile Your Way”.   Those kinds of decisions (disregarding the system level optimizations and trying to optimize only at a subsystem level) might amount to “Agile my way or highway”, irrespective of Approach # 1 or # 2 described above.  Systems thinking is important for Scaling Agile Your Way.

This blog series is not a tutorial on or an in-depth review of SAFe, LeSS, DAD or MAXOS.  I will provide a brief overview of these frameworks for getting started.  I will then present a set of 25 scaling parameters (organized into 6 scaling aspects) that need to be considered to decide what scaling approach and methods are best suited for your specific situation, and what kind of customization will be needed.

SAFe: SAFe is a popular agile scaling framework for “enterprise-class,” large-scale agile projects.  It has great market momentum going for it, with extensive information available in the public domain, and training/certification programs from the Scaled Agile Academy and its partners.  SAFe is a proven and publically available framework for applying agile-lean practices at scale.  Many agile project lifecycle management tool vendors (such as VersionOne and Rally) support SAFe.  I will cover SAFe’s Sweet Spot, Challenge Zone and Unfit Zone, and give examples of how to customize SAFe for your situation in this blog series.

SAFe is often criticized, rather harshly and often unfairly, as being overly prescriptive and hence not suitable for many large-scale agile projects.  In some situations, SAFe is a good fit (Sweet Spot), while in some other situations, SAFe may be in a “Challenge Zone” where some effort (such as enhancement and customizations) will be needed to overcome those challenges.  But even with that effort, you may be better off using SAFe, compared to developing your own set of agile processes and practices from scratch.  However, in some situations, SAFe may be in an “Unfit Zone,” i.e., it is either not applicable or will not work well.  Full disclosure: I am a certified SAFe Program Consultant (SPC).

MAXOS: A relatively new agile-lean framework called MAXOS allows you to scale a particular type of agile methodology called “Continuous Agile,” where teams release working code several times in a day. In fact, after each change, the code becomes releasable shortly, thanks to automated testing, continuous integration, and developer-centric teams.  All teams continuously integrate their code into an enterprise-wide common code base, with a very large number of automated test sets running continuously in a cloud computing environment.  MAXOS is being used at many leading high-technology companies, such as Google, Amazon, Hubspot, and Edmunds.com.   MAXOS is particularly well-suited for large-scale Software-as-Service (SaaS) for consumer mass markets, and for lean startups (based on Eric Ries’ Lean Startup methodology).  MAXOS offers a radically different approach to scaling agile compared to SAFe.  MAXOS also has its own Sweet Spot, Challenge Zone and Unfit Zone, as I will explain in this blog series.  The Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS are very different.  The contrast between SAFe and MAXOS is breathtaking.   If your competition has started to use MAXOS and you are still using SAFe, your competition couldn’t be happier!  On the other hand, if you insist on using MAXOS in situations where SAFe excels, you would be making a poor decision.  Many practices from MAXOS (such as test automation and continuous integration) can be incorporated within SAFe.

At present, MAXOS doesn’t seem to have formal training and certification programs.  I attended MAXOS presentation by Andy Singleton at the Agile 2014 conference, and have reviewed most of the public information about MAXOS, including the eBook on Continuous Agile method.

LeSS: LeSS is regular Scrum applied to large-scale development.  LeSS is developed by Larman and Vodde.  A key message of Scrum is to avoid a cookbook of defined process. Realize that each team and each product will have to inspect and adapt their own Scrum adoption, which will evolve sprint by sprint. Therefore, the suggestions offered by LeSS are no more than that—suggestions.

DAD: DAD is a process decision framework developed by Scott Ambler and his colleagues.  The DAD is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, enterprise-aware, and scalable.  DAD leverages proven strategies from several sources (Scrum, Lean, XP, Kanban, SAFe, DevOps, Agile Unified Process or AgileUP, Agile Modeling, etc.), providing a decision framework to guide your adoption and tailoring them in a context-driven manner.

Although there are differences among SAFe, LeSS and DAD, those differences are dwarfed by their differences from MAXOS.  For example, while SAFe, LeSS and DAD are predicated on cross-functional teams with a number of meetings required, MAXOS advocates developer-centric, highly empowered teams (developers, not QA, decide to release!), and “management automation” to eliminate many meetings.  As LeSS and DAD are not as popular as SAFe at this time, I will not cover them further in this blog series.

You can use the Agile Scaling Knowledgebase (ASK) decision matrix to access a template for comparing SAFe, DAD, LeSS and other scaling agile frameworks.

SAFe and MAXOS cover a fairly large territory of vastly different types of large-scale agile projects.  Once you understand SAFe and MAXOS, and your own unique situation, you may be better off using one of those (with appropriate customizations as needed), rather than creating one from scratch and sustaining your own custom agile processes (an expensive and risky proposition).

There may be unusual situations where neither SAFe nor MAXOS may be a good fit for a large-scale agile project.  I will cover this topic in Part 3 of this series.  If you believe that your large-scale agile project has unique requirements that render both SAFe and MAXOS totally useless, and you have no choice but to create, maintain and sustain your own custom processes for your large-scale agile project, please let us know.  I would be very interested to know about your unique situation and what led you to prefer custom processes from scratch.

Customization approach:  Scrum at Scale (meta)-framework developed by Jeff Sutherland and Alex Brown starts with the basic premise that Scrum is an object-oriented framework.  Scrum at Scale framework is aimed at extending Scrum for large-scale agile projects, while retaining Scrum’s object-oriented architecture.  Scrum at Scale framework, along with its pattern library, are aimed at allowing agile projects to develop their own unique and customized methods for scaling Scrum to large-scale projects.  In Part 4 of this blog series, I will explain salient aspects of Scrum at Scale, and how its object-oriented approach may be used for customizing SAFe for your own unique needs.

Agile Scaling Aspects and Parameters:  Any large-scale agile project needs to consider a number of scaling parameters in order to decide which scaling framework would be most appropriate for its unique needs, or whether it needs a totally custom set of agile processes.  Table 1-4 shows a set of 25 scaling parameters, grouped into 6 scaling aspects:

1.  Teams

2.  Customers/Users

3.  Agile Methods and Environments

4.  Product/Solution

5.  Complexity

6.  Value Chain

The list is a fairly comprehensive, but by no means, exhaustive.  If some of the 25 parameters are not appropriate for your large-scale agile project, you need not consider those parameters.  If any scaling aspect or parameter is missing from the list, please let me know.  Each scaling parameter may take one more values from range of options. For example, “Number of teams” parameter associated with “Teams” scaling aspect has a value in the range of 10 to 1,000.  “Composition of teams” parameter associated with “Teams” scaling aspect can select a value in its range of options: Developer-Centric, Somewhat Cross-Functional with Guest Experts, or Fully Cross-Functional.  Multiple options can also be selected as long as they are not contradictory.  For “Composition of teams” parameter, only 1 out of 3 possible values can be selected.  On the other hand, for “Agile method of choice and required tool support” scaling parameter of “Agile Methods and Environment” scaling aspect (see Table 2), multiple choices are possible, such as Scrum, Scrumban, and Scrum+Lean.

Many of 25 scaling parameters are considered by ASK, DAD and Scrum at Scale frameworks.  Tables 1-4 use the following legend to indicate which scaling parameter is covered by ASK, DAD or Scrum at Scale.

  • A:  ASK
  • S: Scrum at Scale
  • D: DAD/Agility at Scale

Note that some of the 25 scaling parameters are not covered by any of these frameworks.  For example, “# 5. Composition of Teams: Fully Cross-Functional” scaling parameter is covered by all A (ASK), S (Scrum at Scale) and D (DAD); while “# 5. Composition of Teams: Developer-Centric” scaling parameter is not covered by ASK, Scrum at Scale or DAD.

Table1b

Table2b

Table3b

Table4

As you review the information in Tables 1-4, you will realize that the “scaling agile” space is complex and very rich with many choices.  Each organization or a large-scale project is likely to select a different combination of these scaling parameters as relevant; moreover, the value or range of values for each scaling parameter for a project or an organization is likely to be unique.

What agile-lean scaling approach are you considering: SAFe, LeSS, DAD, MAXOS, or something else?   What are your customization needs, and does your selected approach fit well with those needs?  I would love to hear from you either here or by email (Satish.Thatte@VersionOne.com). I’m also on Twitter@smthatte.

Part 2: Scaling Agile Your Way – SAFe vs. MAXOS

Part 3: Scaling Agile Your Way – Sweet Spot, Challenge Zone and Unfit Zone for SAFe and MAXOS

Part 4Scaling Agile Your Way – How to develop and implement your custom approach

Categories: Companies

Xebia KnowledgeCast Episode 3

Xebia Blog - Mon, 09/08/2014 - 16:41

xebia_xkc_podcast
The Xebia KnowledgeCast is a bi-weekly podcast about software architecture, software development, lean/agile, continuous delivery, and big data. Also, we'll have some fun with stickies!

In this third episode,
we get a bit more technical with me interviewing some of the most excellent programmers in the known universe: Age Mooy and Barend Garvelink. Then, I talk education and Smurfs with Femke Bender. Also, I toot my own horn a bit by providing you with a summary of my PMI Netherlands Summit session on Building Your Parachute On The Way Down. And of course, Serge will have Fun With Stickies!

It's been a while, and for those that are still listening to this feed: The Xebia Knowledgecast has been on hold due to personal circumstances. Last year, my wife lost her job, my father and mother in-law died, and we had to take our son out of the daycare center he was in due to the way they were treating him there. So, that had a little bit of an effect on my level of podfever. That said, I'm back! And my podfever is up!

Want to subscribe to the Xebia KnowledgeCast? Subscribe via iTunes, or use our direct rss feed.

Your feedback is appreciated. Please leave your comments in the shownotes. Better yet, use the Auphonic recording app to send in a voicemessage as an AIFF, WAV, or FLAC file so we can put you ON the show!

Credits

Categories: Companies

My agile performance appraisal talk – what I didn’t say…

Growing Agile - Mon, 09/08/2014 - 10:32

After I received the feedback on my Agile 2014 talk on Performance Appraisals without a number, I realised the talk missed the mark for some people. At first I blamed the attendees who obviously didn’t ‘get it’. But now I realised I’d given a talk about my solution to performance appraisals in an agile team, rather than sharing what I have learned about performance appraisals and managing people that would help others design their own solution.

So here it is, what I’ve learned about managing performance…

1. You don’t need to manage performance. As an employee I have never been motivated to do anything in my job because of a performance management discussion. Just give people feedback, and create an environment for them to thrive and they will manage themselves.

2. You don’t need to measure people or their performance. People are far to complex to be measured by a simple metric. Imagine measuring people’s height and using it as a performance metric. It’s laughable right? Well actually so is just about any other measurement you can come up with. Don’t measure the people, measure the important things like customer satisfaction, lead time, profitability.

3. You don’t need team performance appraisals with agile. They are built in. In the review, users get to tell the team what they think of the product and in the retrospective team mates get to tell each other what they think about the process. Rather focus on making these meetings functional than introducing a team component on performance appraisals.

4. Performance appraisals are harmful. If you can abandon them completely, then do so. My talk showed what I did because I couldn’t abandon them completely, but the net result is I filled in a spreadsheet for HR instead of doing performance appraisals. It was at least a compromise that didn’t impact my team. Yes I was gaming the system, because I didn’t have the influence to remove them, but at least I removed the impact of them on my team, who were blissfully unaware.

5. People are not motivated by money. You don’t need to pay star performers more than other people. The only star performers I paid more were the ones who were significantly underpaid compared to their peers. Pay people a good enough salary that they don’t worry about it, and make it a great environment.

6. Ratings don’t determine increases, business does. Let’s all stop pretending that ratings are actually what determines increases. In every job I’ve ever had the business looks at their profitability and costs and comes up with a budget for increases. Each manager is given a bucket to spend as they see fit. We then have a complex process of rating people that ends in Bob getting 1% more than Mary. It’s pointless. There is much more variation based on the size of the bucket than on the ratings. As a manager use your discretion to split the pot in the most fair way. If people want to be paid more, they can all help make the increase pot bigger by making the company more profitable.

7. The only thing you need is feedback. As a manager your job is to give people feedback. Do it verbally, face to face, often. Learn to do it well. That is it.

Categories: Companies

Getting started with Salt

Xebia Blog - Mon, 09/08/2014 - 10:07

A couple of days ago I had the chance to spend a full day working with Salt(stack). On my current project we are using a different configuration management tool and my colleagues there claimed that Salt was simpler and more productive. The challenge was easily set, they claimed that a couple of people with no Salt experience, albeit with a little configuration management knowledge, would be productive in a single day.

My preparation was easy, I had to know nothing about Salt....done!

During the day I was working side by side with another colleague who knew little to nothing about Salt. When the day started, the original plan was to do a quick one hour introduction into Salt. But as we like to dive in head first this intro was skipped in favor of just getting started. We used an existing Vagrant box that spun up a Salt master & minion we could work on. The target was to get Salt to provision a machine for XL Deploy, complete with the customizations we were doing at our client. Think of custom plugins, logging configuration and custom libraries.

So we got cracking, running down the steps we needed to get XL Deploy installed. The steps were relatively simple, create a user & group, get the installation files from somewhere, install the server, initialize the repository and run it as a service.

First thing I noticed is that we simply just could get started. For the tasks we needed to do (downloading, unzipping etc.) we didn't need any additional states. Actually, during the whole exercise we never downloaded any additional states. Everything we needed was provided by Salt from the get go. Granted, we weren't doing anything special but it's not a given that everything is available.

During the day we approached the development of our Salt state like we would a shell script. We started from the top and added the steps needed. When we ran into issues with the order of the steps we'd simply move things around to get it to work. Things like creating a user before running a service as that user were easily resolved this way.

Salt uses yaml to define a state and that was fairly straight forward to use. Sometimes the naming used was strange. For example the salt.state.archive uses the parameter "source" for it's source location but "name" for it's destination. It's clearly stated in the docs what the parameter is used for, but a strange convention nonetheless.

We also found that the feedback provided by Salt can be scarce. On more than one occasion we'd enter a command and nothing would happen for a good while. Sometimes there would eventually be a lot of output but sometimes there wasn't.  This would be my biggest gripe with Salt, that you don't always get the feedback you'd like. Things like using templates and hierarchical data (the so-called pillars) proved easy to use. Salt uses jinja2 as it's templating engine, since we only needed simple variable replacement it's hard to comment on how useful jinja is. For our purposes it was fine.  Using pillars proved equally straightforward. The only issue we encountered here was that we needed to add our pillar to our machine role in the top.sls. Once we did that we could use the pillar data where needed.

The biggest (and only real) problem we encountered was to get XL Deploy to run as a service. We tried two approaches, one using the default service mechanism on Linux and the second using upstart. Upstart made it very easy to get the service started but it wouldn't stop properly. Using the default mechanism we couldn't get the service to start during a Salt run. When we send it specific commands it would start (and stop) properly but not during a run. We eventually added a post-stop script to the upstart config to make sure all the (child) processes stopped properly.

At the end of the day we had a state running that provisioned a machine with XL Deploy including all the customizations we wanted. Salt basically did what we wanted. Apart from the service everything went smooth. Granted, we didn't do anything exotic and stuck to rudimentary tasks like downloading, unzipping and copying, but implementing these simple tasks remained simple and straightforward. Overall Salt did what one might expect.

From my perspective the goal of being productive in a single day was easily achieved. Because of how straightforward it was to implement I feel confident about using Salt for more complex stuff. So, all in all Salt left a positive impression and I would like to do more with it.

Categories: Companies

Are Testers still relevant?

Xebia Blog - Sun, 09/07/2014 - 23:07

Last week I talked to one of my colleagues about a tester in his team. He told me that the tester was bored, because he had nothing to do. All the developers wrote and executed their tests themselves. Which makes sense, because the tester 2.0 tries to make the team test infected.

So what happens if every developer in the team has the Testivus? Are you still relevant on the Continuous Delivery train?
Come and join the discussion at the Open Kitchen Test Automation: Are you still relevant?

Testers 1.0

Remember the days when software testers where consulted after everything was built and released for testing. Testing was a big fat QA phase, which was a project by itself. The QA department consisted of test managers analyzing the requirements first. Logical test cases were created and were subordinated to test executors, who created physical test cases and executed them manually. Testers discovered conflicting requirements and serious issues in technical implementations. Which is good obviously. You don't want to deliver low quality software. Right?

So product releases were being delayed and the QA department documented everything in a big fat test report. And we all knew it: The QA department had to do it all over again after the next release.

I remember being a tester during those days. I always asked myself: Why am I always the last one thinking about ways to break the system? Does the developer know how easily this functionality can be broken? Does the product manager know that this requirement does not make sense at all?
Everyone hated our QA department. We were portrayed as slow, always delivering bad news and holding back the delivery cycle. But the problem was not delivering the bad news. The timing was.

The way of working needed to be changed.

Testers 2.0

We started training testers to help Agile teams deliver high quality software during development: The birth of the Tester 2.0 - The Agile Tester.
These testers master the Agile Manifesto, processes and methods that come with it. Collaboration about quality is the key here. Agile Testing is a mindset. And everyone is responsible for the quality of the product. Testers 2.0 helped teams getting (more) test infected. They thought like a researcher instead of a quality gatekeeper. They became part of the software development and delivery teams and they looked into possibilities to speed up testing efforts. So they practiced several exploratory testing techniques. Focused on reasonable and required tests, given the constraints of a sprint.

When we look back at several Agile teams having a shared understanding about Agile Testing, we saw many multidisciplinary teams becoming two separate teams: One is for developers and the other for QA / Testers.
I personally never felt comfortable in those teams. Putting testers with a group of developers is not Agile Testing. Developers still left testing for testers, and testers passively waited for developers to deploy something to be tested. At some point testers became a bottleneck again so they invested in test automation. So testers became test automators and build their own test code in a separate code base than development code. Test automators also picked tools that did not foster team responsibility. Therefore Test Automation got completely separated from product development. We found ways to help testers, test automators and developers to collaborate by improving the process. But that was treating the symptom of the problem. Developers were not taking responsibility in automated tests. And testers did not help developers designing testable software.

We want test automators and developers to become the same people.

Testers 3.0

If you want to accelerate your business you'll need to become iterative, delivering value to production as soon as possible by doing Continuous Delivery properly. So we need multidisciplinary teams to shorten feedback loops coming from different point of views.

Testers 3.0 are therefore required to accelerate the business by working in these following areas:

Requirement inspection: Building the right thing

The tester 3.0 tries to understand the business problem of requirements by describing examples. It's important to get common understanding between the business and technical context. So the tester verifies them as soon as possible and uses this as input for Test Automation and use BDD as a technique where a Human Readable Language is fostered. These testers work on automated acceptance tests as soon as possible.

Test Automation: Boosting the software delivery process

When common understanding is reached and the delivery team is ready to implement the requested feature, the tester needs programming skills to make the acceptance tests in a clean code state. The tester 3.0 uses appropriate Acceptance Test Driven Development tools (like Cucumber), which the whole team supports. But the tester keeps an eye out for better, faster and easier automated testing frameworks to support the team.

At the Xebia Craftsmanship Seminar (a couple of months ago) someone asked me if testers should learn how to write code.
I told him that no one is good at everything. But the tester 3.0 has good testing skills and enough technical baggage to write automated acceptance tests. Continuous Delivery teams have a shared responsibility and they automate all boring steps like manual test scripts, performance and security tests. It's very important to know how to automate; otherwise you'll slow down the team. You'll be treated the same as anyone else in the delivery team.
Testers 3.0 try to get developers to think about clean code and ensuring high quality code. They look into (and keep up with) popular development frameworks and address the testability of it. Even the test code is evaluated for quality attributes continuously. It needs the same love and caring as getting code into production.

Living documentation: Treating tests as specifications

At some point you'll end up with a huge set of automated tests telling you everything is fine. The tester 3.0 treats these tests as specifications and tries to create a living document, which is used for long term requirements gathering. No one will complain about these tests when they are all green and passing. The problem starts when tests start failing and no one can understand why. Testers 3.0 think about their colleague when they write a specification or test. They need to clearly specify what is being tested in a Human Readable Language.
They are used to changing requirements and specifications. And they don't make a big deal out of it. They understand that stakeholders can change their mind once a product comes alive. So the tester makes sure that important decisions made during new requirement inspections and development are stored and understood.

Relevant test results: Building quality into the process

Testers 3.0 focus on getting extreme fast feedback to determine the software quality of software products every day. Every night. Every second.
Testers want to deploy new working software features into production more often. So they do whatever it takes to build a high quality pipeline decreasing the quality feedback time during development.
Everyone in your company deserves to have confidence in the software delivery pipeline at any moment. Testers 3.0 think about how they communicate these types of feedback to the business. They provide ways to automatically report these test results about quality attributes. Testers 3.0 ask the business to define quality. Knowing everything was built right, how can they measure they've built the right thing? What do we need to measure when the product is in production?

How to stay relevant as a Tester

So what happens when all of your teammates are completely focused on high quality software using automation?

Testing does not require you to manually click, copy and paste boring scripted test steps you didn't want to do in the first place. You were hired to be skeptical about anything and make sure that all risks are addressed. It's still important to keep being a researcher for your team and test curiosity accordingly.

Besides being curious, analytical and having great communication skills, you need to learn how to code. Don't work harder. Work smarter by analyzing how you can automate all the boring checks so you'll have more time discovering other things by using your curiosity.

Since testing drives software development, and should no longer be treated as a separate phase in the development process, it's important that teams put test automation in the center of all design decisions. Because we need Test Automation to boost the software delivery by building quality sensors in every step of the process. Every day. Every night. Every second!

Do you want to discuss this topic with other Testers 3.0?  Come and join the Open Kitchen: Test Automation and get on board the Continuous Delivery Train!

 

Categories: Companies

Project Management with Kanban Class Curriculum

This is the first look at one of our new role-based training classes. This is specifically targeted at project managers and related roles such as service delivery manager, program manager, and anyone with responsibility for delivering projects, product releases and similar batches of packaged creative or knowledge work. This new curriculum is scoped within the Modern Management Framework and will be available in 2-day class format at the Advanced Practitioner level with the LeanKanban University curriculum structure. Project Management with Kanban classes will be available publicly and privately from October 1st 2014 from David J. Anderson & Associates. From November 1st, and Accredited Advanced Kanban Trainer (AAKT) will be able to offer the class through the LeanKanban University certified training program.

read more

Categories: Companies

Kanban Coaching Professional Masterclass Curriculum

For the first time, I'm posting our curriculum for the Kanban Coaching Professional Masterclass. This new curriculum is scoped within the Modern Management Framework and takes effect in Masterclasses offered after November 1st 2014.

read more

Categories: Companies

Lean and Kanban at Scale

Al Shalloway, CEO of Net Objectives, discusses how to apply Lean and Kanban at scale to manage software initiatives more effectively. About this Webinar The essence of Kanban is to manage the workflow of value added activities by limiting how much work is being done. Al uses Lean thinking to extend Kanban to the portfolio, program, […]

The post Lean and Kanban at Scale appeared first on Blog | LeanKit.

Categories: Companies

Product Ownership – Dealing with capacity and prioritisation

Growing Agile - Fri, 09/05/2014 - 09:03

Last night we did a talk for SUGSA (the Scrum User Group of South Africa). It was a blast and full of eager learners icon smile Product Ownership   Dealing with capacity and prioritisation

We spoke about 2 techniques – one to talk and understand capacity and one to assist with prioritisation. The slides are on slideshare.

And you can read about the techniques, The Freeway Analogy and Prioritise your Backlog. This post might also help: A Handy Guide for Coaching Product Owners.

If you are keen to read about more of these workshops, please buy our books!

BookAR 300x300 Product Ownership   Dealing with capacity and prioritisationBookMB 300x300 Product Ownership   Dealing with capacity and prioritisationBookRP 300x300 Product Ownership   Dealing with capacity and prioritisation

 Here is a writeup from the committee: http://sugsa.org.za/2014/09/event-report-product-owners-dealing-with-capacity-and-prioritisation/.

Categories: Companies

LeanKanban Kanban Foundation Curriculum

As part of our continuing sneak peak of the new LeanKanban Modern Management Framework, I want to show how we are using it to define and communicate the curriculum for individual training classes. We are now offering a wide range of training classes at different levels. Here we look at the 2-day Kanban Foundation level training...

read more

Categories: Companies

Welcome to the Swift Playground

Xebia Blog - Thu, 09/04/2014 - 20:16

Imagine... You're working in swift code and you need to explain something to a co-worker. Easiest would be to just explain it and show the code right. So you grab your trusty editor and type some markdown.

let it = "be awesome"

Great!

So now you have a file filled with content:
swift-markdown

But it would be better if it looked like:

playground

Well you can and it's super simple, all you need is some Markdown and:

npm install -g swift-playground-builder

After that it's a matter of running:

playground my-super-nice-markdown-with-swift-code.md

Enjoy!

More info: https://github.com/jas/swift-playground-builder

Categories: Companies

Project Management with Kanban (Part 4) - Risk Review

This is my final blog post in the series on project management with Kanban. If you haven't seen the previous three posts read them here, Part 1, Part 2, Part 3. This post looks at how project managers can help with risk management and controlling the average lead time and the the lead time distribution. This is important to insure that the forecasts described in Part 3 remain trustworthy and accurate through the duration of the project. The Blocker Clustering technique described in this post was developed by Klaus Leopold and can be used to drive process improvement as well as managing project risk. You can read his original blog post, Blocker Clusters.

read more

Categories: Companies

7 Things I Validated in My First Month With VersionOne

Agile Management Blog - VersionOne - Thu, 09/04/2014 - 15:05

What’s your lucky number? In June, I attended the Agile West BSC/ADC conference in Las Vegas and didn’t do so well at the roulette table; however, two months later on 7/21/14 (lucky 7s) I placed an even bigger bet; not on red, but on Pantone Color Number 216. It’s the signature color of VersionOne, the all-in-one agile project management tool and services provider.

After almost seven years of building up my agile acumen at Cars.com, I decided that it was time to close that season of my career, and I began researching and planning my next career challenge. I outlined three key pillars that were very important to me and my ability to truly enjoy going to work every day:

  • Customer Centric Vision – Having the ability to know WHY what we do matters to customers, and matching values and alignment to priorities.
  • Clear Agile Direction – Finding a company who is moving the agile ball further down the line.
  • Fun and Innovative Culture – Life is too short and if you are going to work hard, it makes it much easier to find the joy in your job if you have fun doing it.

These were the most important traits I was seeking in part because they were the things that made me love being at Cars.com. I plugged into my network, had some interviews (and one offer that didn’t work out), and continued my quest to not settle until I found a career that valued these same traits. Then, just when I thought that finding my career “Match.com” was out of reach, I found an opening for a Chicago-based Product Speversiononecialist that turned out to be the perfect blend of vision, direction and fun.

Luckily for me, it was also at a place I knew very well, VersionOne. After a few interviews and a relatively painless courtship, I accepted the position and can report that so far it has been a jackpot payoff.

Since my start at VersionOne, I have validated or learned seven key things that I believe you can also learn from, no matter where you work:

  1. The customer is king (or queen); however, not everyone is a customer – If the slipper doesn’t fit, you can’t force it!
  2. Community is very important – Sometimes a company does things because it’s for the greater good.
  3. You can’t fake culture – If you’ve got a great culture, you’ve got it. Hang onto it.
  4. Agile is a mindset, not a methodology – Like culture, the question is not “Are you Agile?” but rather, “How Agile are you?” If you aren’t sure, take this Agile Development Quiz.
  5. Cold beer, anyone? A cold beverage and a game of pool after work is still a great way to end the day. When they say “Work Hard, Play Hard,” believe them!
  6. Valuable training is essential – Among the many other benefits, new-hire training as a group bonds people together and to the company.
  7. VersionOne is a great place to be because of the people, agile project management products and services to help companies achieve agile success, as well as VersionOne’s commitment to the agile community at large.

Going into my Product Specialist position I tried hard to find red flags, indicators that would give me some warning or reason to pause. At the end of the day, every flag I saw was Pantone 216. It’s my new lucky number!

I hope you find your lucky number, whether it’s a career at VersionOne, a business engagement with us, or something totally unrelated!

Read more on my personal blog at a12p.blogspot.com.

 

Categories: Companies

Webinar: DevOps for Agility

Rally Agile Blog - Thu, 09/04/2014 - 13:00

Today’s fast-moving markets expose threats and opportunities at every turn. Whether you’re a large enterprise or a small startup, it’s no longer enough to simply practice Agile development. To survive — and thrive — in this disruptive environment, you need agility throughout your organization.

Join Rally and Chef for a webinar about the role of DevOps in building agility and responsiveness. Learn more about how Rally practices continuous deployment, accelerates application development, and tightens customer feedback loops. Hear how you can institutionalize DevOps and use Chef to support a speed-focused approach. 

          

DATE: Thursday, September 4

TIME: 11:00 AM Pacific / 2:00 PM Eastern

PARTICIPANTS: 

  • Jonathan Chauncey, developer at Rally Software
  • Jeff Smith, development manager at Rally Software
  • Colin Campbell, director of patterns and practices at Chef
  • [moderator] Alan Shimel, editor-in-chief, DevOps.com

Register here: http://devops.megameeting.com/registration/?id=1949-232488

Rally Software
Categories: Companies

Scaling Agile with New SAFe Templates

Since day one, LeanKit has been dedicated to helping organizations scale Lean and Agile practices across the enterprise. Discover how LeanKit is simplifying the adoption of the Scaled Agile Framework® (SAFe) with new portfolio, program, and team level board templates. Implementing SAFe with LeanKit Lean thinking is foundational to SAFe — making LeanKit uniquely suited to support […]

The post Scaling Agile with New SAFe Templates appeared first on Blog | LeanKit.

Categories: Companies

React in modern web applications: Part 1

Xebia Blog - Tue, 09/02/2014 - 13:00

At Xebia we love to share knowledge! One of the ways we do this is by organizing 1-day courses during the summer. Together with Frank Visser we decided to do a training about full stack development with Node.js, AngularJS and Facebook's React. The goal of the training was to show the students how one could create a simple timesheet application. This application would use nothing but modern Javascript technologies while also teaching them best practices with regards to setting up and maintaining it.

To further share the knowledge gained during the creation of this training we'll be releasing several blog posts. In this first part we'll talk about why to use React, what React is and how you can incorporate it into your Grunt lifecycle.

This series of blog posts assume that you're familiar with the Node.js platform and the Javascript task runner Grunt.

What is React?

ReactJS logo

React is a Javascript library for creating user interfaces made by Facebook. It is their answer to the V in MVC. As it only takes care of the user interface part of a web application React can be (and most often will be) combined with other frameworks (e.g. AngularJS, Backbone.js, ...) for handling the MC part.

In case you're unfamiliar with the MVC architecture, it stands for model-view-controller and it is an architectural pattern for dividing your software into 3 parts with the goal of separating the internal representation of data from the representation shown to the actual user of the software.

Why use React?

There are quite a lot of Javascript MVC frameworks which also allow you to model your views. What are the benefits of using React instead of for example AngularJS?

What sets React apart from other Javascript MVC frameworks like AngularJS is the way React handles UI updates. To dynamically update a web UI you have to apply DOM updates whenever data in your UI changes. These DOM updates, compared to reading data from the DOM, are expensive operations which can drastically slow down your application's responsiveness if you do not minimize the amount of updates you do. React took a clever approach to minimizing the amount of DOM updates by using a virtual DOM (or shadow DOM) diff.

In contrast to the normal DOM consisting of nodes the virtual DOM consists of lightweight Javascript objects that represent your different React components. This representation is used to determine the minimum amount of steps required to go from the previous render to the next render. By using an observable to check if the state has changed React prevents unnecessary re-renders. By calling the setState method you mark a component 'dirty' which essentially tells React to update the UI for this component. When setState is called the component rebuilds the virtual DOM for all its children. React will then compare this to the current virtual sub-tree for the same component to determine the changes and thus find the minimum amount of data to update.

Besides efficient updates of only sub-trees, React batches these virtual DOM batches into real DOM updates. At the end of the React event loop, React will look up all components marked as dirty and re-render them.

How does React compare to AngularJS?

It is important to note that you can perfectly mix the usage of React with other frameworks like AngularJS for creating user interfaces. You can of course also decide to only use React for the UI and keep using AngularJS for the M and C in MVC.

In our opinion, using React for simple components does not give you an advantage over using AngularJS. We believe the true strength of React lies in demanding components that re-render a lot. React tends to really outperform AngularJS (and a lot of other frameworks) when it comes to UI elements that require a lot of re-rendering. This is due to how React handles UI updates internally as explained above.

JSX

JSX is a Javascript XML syntax transform recommended for use with React. It is a statically-typed object-oriented programming language designed for modern browsers. It is faster, safer and easier to use than Javascript itself. Although JSX and React are independent technologies, JSX was built with React in mind. React works without JSX out of the box but they do recommend using it. Some of the many reasons for using JSX:

  • It's easier to visualize the structure of the DOM
  • Designers are more comfortable making changes
  • It's familiar for those who have used MXML or XAML

If you decide to go for JSX you will have to compile the JSX to Javascript before running your application. Later on in this article I'll show you how you can automate this using a Grunt task. Besides Grunt there are a lot of other build tools that can compile JSX. To name a few, there are plugins for Gulp, Broccoli or Mimosa.

An example JSX file for creating a simple link looks as follows:

/** @jsx React.DOM */
var link = React.DOM.a({href: 'http://facebook.github.io/react'}, 'React');

Make sure to never forget the starting comment or your JSX file will not be processed by React.

Components

With React you can construct UI views using multiple, reusable components. You can separate the different concepts of your application by creating modular components and thus get the same benefits when using functions and classes. You should strive to break down the different common elements in your UI into reusable components that will allow you to reduce boilerplate and keep it DRY.

You can construct component classes by calling React.createClass() and each component has a well-defined interface and can contain state (in the form of props) specific to that component. A component can have ownership over other components and in React, the owner of a component is the one setting the props of that component. An owner, or parent component can access its children by calling this.props.children.

Using React you could create a hello world application as follows:

/** @jsx React.DOM */
var HelloWorld = React.createClass({
  render: function() {
    return <div>Hello world!</div>;
  }
});

Creating a component does not mean it will get rendered automatically. You have to define where you would like to render your different components using React.renderComponent as follows:

React.renderComponent(<HelloWorld />, targetNode);

By using for example document.getElementById or a jQuery selector you target the DOM node where you would like React to render your component and you pass it on as the targetNode parameter.

Automating JSX compilation in Grunt

To automate the compilation of JSX files you will need to install the grunt-react package using Node.js' npm installer:

npm install grunt-react --save-dev

After installing the package you have to add a bit of configuration to your Gruntfile.js so that the task knows where your JSX source files are located and where and with what extension you would like to store the compiled Javascript files.

react: {
  dynamic_mappings: {
    files: [
      {
        expand: true,
        src: ['scripts/jsx/*.jsx'],
        dest: 'app/build_jsx/',
        ext: '.js'
      }
    ]
  }
}

To speed up development you can also configure the grunt-contrib-watch package to keep an eye on JSX files. Watching for JSX files will allow you to run the grunt-react task whenever you change a JSX file resulting in continuous compilation of JSX files while you develop your application. You simply specify the type of files to watch for and the task that you would like to run when one of these files changes:

watch: {
  jsx: {
    files: ['scripts/jsx/*.jsx'],
    tasks: ['react']
  }
}

Last but not least you will want to add the grunt-react task to one or more of your grunt lifecycle tasks. In our setup we added it to the serve and build tasks.

grunt.registerTask('serve', function (target) {
  if (target === 'dist') {
    return grunt.task.run(['build', 'connect:dist:keepalive']);
  }

  grunt.task.run([
    'clean:server',
    'bowerInstall',
    <strong>'react',</strong>
    'concurrent:server',
    'autoprefixer',
    'configureProxies:server',
    'connect:livereload',
    'watch'
  ]);
});

grunt.registerTask('build', [
  'clean:dist',
  'bowerInstall',
  'useminPrepare',
  'concurrent:dist',
  'autoprefixer',
  'concat',
  <strong>'react',</strong>
  'ngmin',
  'copy:dist',
  'cdnify',
  'cssmin',
  'uglify',
  'rev',
  'usemin',
  'htmlmin'
]);
Conclusion

Due to React's different approach on handling UI changes it is highly efficient at re-rendering UI components. Besides that it's easily configurable and integrate in your build lifecycle.

What's next?

In the next article we'll be discussing how you can use React together with AngularJS, how to deal with state in your components and how to avoid passing through your entire component hierarchy using callbacks when updating state.

Categories: Companies

Retrospective plan for a new scrum team

Growing Agile - Mon, 09/01/2014 - 10:00

We feel it is important for teams new to Scrum to get value from their retrospectives right from the beginning. With new teams we usually facilitate the first retrospective with the ScrumMasters observing. We share our retro plan with them in advance so they can follow what we are doing.

Here is a simple retrospective plan following the 5 steps for a team new to Scrum. We made sure to keep the focus positive and introduce basic techniques like brainstorming, clustering and dot voting that the teams are likely to use again and again. Since the team is new all the techniques need to be explained. We also made sure that the team picked an action that was within their own control, since many new Scrum teams believe that things outside the team need to change, and don’t realise how much they can change themselves.

 Retrospective plan for a new scrum team  Retrospective plan for a new scrum team

Categories: Companies

Learning about Risk & WIP from Real Life

I find that real life examples can help people understand why you can't talk about kanban systems without talking about risk, and why you can't calculate WIP limits without understanding work item types, risk and classes of service. Consider the humble problem of "how many shirts do you need hanging in your closet?"...

read more

Categories: Companies

Sneak Peak at Modern Management Framework

Image: 

In China, "Kanban" simply means "looking at the board." For a Chinese audience, Kanban is encapsulated in the cartoon on the cover of my Kanban: Successful Evolutionary Change for your Technology Business. They don't need to look further than the characters standing in front of the board. Hence, to a Chinese mind, our management approach is centered around a standup meeting. All well and good and why not?

However, a senior executive at one of our clilents felt that this perception was likely to undermine the true value and the potential impact of our teachings on his business. So he suggested that we give the wider collection of ideas, intellectual property and teaching tools, a different name. It so happens I'd been thinking along similar lines and introducing terms and branding in our business to lay the foundation for this. So here it is, "The Modern Management Framework." This isn't new. It's the collection of our existing class curriculum and consulting tools but presented altogether in one place for the first time and under one banner.

read more

Categories: Companies

This is Way Better Than the Ice Bucket Challenge!

Agile Management Blog - VersionOne - Thu, 08/28/2014 - 22:16

If you feel like there’s a lot of time being idled away on the Ice Bucket Challenge and other wacky, brainless activities, we have a better idea to spend your time. In just 10 minutes you could do something really valuable for the agile software community.

But first I’m hoping to get just a tiny smile out of you by sharing something I wrote on our Product Blog earlier this week — just in case you aren’t subscribed there. If you are, just ignore this and go straight to the punch line.

I posed this question:

What’s the Best Way to Spend 10 Minutes?

Let’s think about this for a minute…

You could:

  • Ice-bucket challenge someone
  • Set a stapler in a Jell-o moldStapler
  • Crash someone’s Facebook by inviting them to Candy Crush
  • Add a ‘Blue Screen of Death’ screen saver to your boss’s laptop
  • Load a DVORAK driver onto a PC with a normal keyboard
  • Clean those 24 sticky coffee rings off your desk
  • Assign a bunch of fake stories to people

But if you really want to make a lasting and meaningful impact on the agile software community, please find 10 minutes to take the 2014 State of Agile survey.

Why?

2014_SOA_banner_300x250

“The annual State of Agile survey has become one of the most comprehensive industry surveys serving the agile community. The survey gives agile software professionals an extensive set of relevant statistics, peer guidance and validation that can be very helpful in making smarter decisions about their delivery process.”

- SD Times Editor-in-Chief David Rubinstein

Now in its 9th year, the State of Agile has helps agile practitioners, consultants, technology students, professors, bloggers and business people in all industries better understand agile methods and practices. The survey runs late summer through mid-September and VersionOne publishes the report in Q4 or early Q1.

If you take it, you get:

  • Entered into a drawing for 1 of 9 SONOS wireless HiFi systems (each worth 600 bucks)
  • Exclusive, early access to the data sample from 2,000-4,000 respondents in your industry
  • Satisfaction that you helped others make informed decisions about their agile practices – in just 10 minutes

What are you waiting for? Take the State of Agile survey now.

take survey now image

 

Categories: Companies