You need to know what's on the cutting-edge of technology. Find out what's coming and the unique Warptest POV with just one click on the "Blog" tile.

All posts tagged Agile

Atlassian Bought Trello For $425 million…

With Atlassian announcing the big Trello news today, should you be backing up your tickets and looking for another Agile style task management app?

Originally the brainchild of Fog Creek Software and their owner, Joel Spolsky forged their own path and became an independent company.

This slideshow requires JavaScript.

Arguably the most popular of the ticket / post-it style web apps for managing tasks, Trello delivered an intuitive, lightweight solution for those tired of kludgy, unwieldy tools.

Atlassian, the company behind Jira and a slew of other products can be considered the market leader in ALM (Application Lifecycle Management) software both on local servers and the cloud.

So, If Atlassian already has Jira, a powerhouse application for managing projects why would they buy it?

Trello was the go-to option for small companies with a lean perspective and strong Agile methodologies.

Is Trello a “buy it to kill it” acquisition?

There Are No Magic Bullets In The Land of ALM

Trello is by no means a perfect standalone solution for managing your product lifecycle. It does task management well, has some really strong integrations like Slack but compare it to solutions like Github or Gitlab and it falls short.

Github and Gitlab have been in competition to deliver a lightweight, easy to implement, comprehensive ALM solution and they started from the other end of the lifecycle. Both Git (source code) repository management tools. Github has evolved with a wide range of integrations and both now include:

  • Web application for user access and management
  • Issue Tracking
  • Agile Ticket Board
  • Wiki / web pages for individual projects

Trello - githubTrello - gitlab

In a nutshell both companies are fighting hard to be the one-stop ALM cloud solution. Trello meanwhile, created a strong product that integrates with others and offered strong competition to Atlassian’s toolset. Especially Jira but, both have a major shortcoming: companies grow out of them too fast. Gitlab needs to play catch up with their feature set.

If Microsoft Team Foundation Server (TFS) with its Test Manager and full Visual Studio integration is a high-end boom-box stereo; then Jira and the associated Atlassian products are akin to a stackable, component stereo.

The Warptest POV

At the end of the day, the ALM solution you select must match your requirements, budget and technical ability. If you are a bootstrapped startup, used to doing things fast then your needs are very different from an established company with several products / projects.

To answer the original question, will Atlassian kill off Trello? Absolutely not.

Atlassian need a lightweight, lean alternative to compete with the Github / Gitlab ALM marketshare. Expect Trello to receive some tight integration with Bitbucket and Confluence. How will Atlassian address the problem that Trello doesn’t handle Issue Tracking well?

If Atlassian changes one thing in Trello it will to add Issues as subtasks of Tickets or create some form of permalink between the two. Trello tickets = stories and Issues or bugs will have an indexable, searchable relationship.

Atlassian will be able to box in both the heavyweight and lightweight arena. Or do you think it’s time to backup your Trello projects?

Agile Actually Does Not Have Low Hanging Fruit…

Are you “doing” Agile? Scrum or Kanban? Doesn’t matter. Probably some of you aren’t actually implementing or running with Agile. Even if you believe you are.

Sorry to disappoint you but this boils down to realizing that Agile does in fact have no low hanging fruit.

Agile Low Hanging Fruit - Tree and Chicken

What Does That Even Mean?

Low hanging fruit, the easily reached, easily attainable target. Ever been up in a cherry picker? That sense as the hydraulics lift you into the air in that small metal basket. As the basket vibrates and you hold on and then … yep, you look down and realize just how fast you got that high up. Agile is like that. Implementing Scrum or Kanban the first time feels like that, especially for the matrix, CMMI and waterfall crowd. Where’s my safety net? Ironically, Agile is meta. The more iterations you do, the more confident you get.

Unless you fall prey to the illusion that certain activities within Agile are easy and you can cherry pick those and ignore the tough stuff. It becomes about performing ritual or kata for its own sake instead of a deeper understanding of why and how to do things, and do them right.

Kata is mindful and any martial artist will explain the benefits of understanding their purpose. Like many others, I’ve applied the kata concept to testing in the past.

Don’t do these. No really, don’t.

There is one more arguably, having tools that don’t integrate, communicate or display actionable information. Allowing technical debt to fester.

If any or all of these are happening with your Agile team then you fell into the illusory trap of low hanging fruit.

This slideshow requires JavaScript.

The Warptest POV

At this point you may be thinking all is lost or getting a bit annoyed. None of this is irreversible and the solution lies in the Principles behind the Agile Manifesto. If you have never read this and or don’t review it with your team, then this is the first change to make. Heck make this the default page in your team browsers, print it big for each work-space and read it aloud together.

See the photo above, I didn’t choose it just for the tree but also for the chicken below. I was sorry to see the chicken and pig analogy dropped (albeit for some evident reasons). The allegory has benefit but is loaded with negative connotation. Find another story that works for you.

Invest in your people. Train them and give them the knowledge and skills to succeed. We can’t just say to a team member, “Hey mate, you’re Scrum Master from now on.” They need to know what a Scrum Master does, how to do it and they will need guidance and help. A Certified Scrum Master course wouldn’t hurt either.

Make the changes that need making and do so fearlessly but not aggressively. Use honey, not vinegar.

Why is all this important? If you leave things as they are, stuck in some bastardized version of Agile then you are plotting your own failure. It won’t work and management will consider Agile a failure. This is a disservice to your efforts, your product and Agile itself.

The point of all this is to drive success. Some of the things you shouldn’t do are the end of a path taken that gives you short term, warm and fuzzy self-gratification instead of keeping your eye on strategic success.

This always makes me think of the scene in Arnold’s Conan the Barbarian where he and his companions are asked,

What is best in life?

Conan knows the answer and so should you. In the case of your team and product it’s adhering to a concrete definition of success. For me that is happy customers who come back for more of our product.

What’s your definition of success?

angry tester

Software Testing…

…can often be perceived as much as an art as a science but there are certain patterns and phrases that reproduce from project to project: –

Image thanks to Office365.

  1. This bug doesn’t reproduce in my Development Environment. The flip side of this is, “It’s a known bug”: when either of these are uttered you can pretty much assume a unicorn just died… horribly.
  2. Automated testing will solve all our testing issues and find all the bugs.
  3. We have a zero tolerance attitude to bugs.
  4. Unit testing? We don’t need that here, it only slows things down.
  5. Who is Manuel Testing?
  6. Can you please stop talking to the developers about bugs? It stops them working.
  7. We invented Agile but we have a unique blend of it with Waterfall and bits of CMMI.
  8. No, no, no! I’m telling you. It’s a feature not a bug.
  9. Why do you need to understand how the customer will use the software? You’re Testing not Product or Sales.
  10. We maintain a proprietary Bug Tracking System we built on top of Excel.

But my all time favorite for real world testing albeit not software testing is:

Here’s your bulletproof vest. If it doesn’t work then bring it back and we’ll exchange it.

Think … about … it. (This really happened to me).

The Warptest POV

Whilst these are amusing to encounter they are also warning signs particularly for the Software Testing professional who works on projects. It is beyond importance to be aware of the work culture and management buy-in / comprehension of what Testing entails, why a specific tool or methodology is being recommended and whether all your efforts will result in a positive change or not.

When I was doing my certification as a Scrum Master the group were asked the best response to this scenario:

Your team are working successfully and to schedule based on their commitments. A manager walks in and takes two members of your team away mid-sprint. When you discuss changes to the schedule due to loss of resources the answer you get is, “We expect you to cope and meet the deadlines regardless”.

Many of the class came up with creative responses involving negotiation, refactoring schedules etc. but the Agile Coach giving the class responded,

“You are all wrong. You update your resume.”

There are software testing jobs like any other jobs that you simply shouldn’t take unless you are prepared for failure on the way.

Sometimes it is possible to pull a testing rabbit out the hat but it requires a strong team and most likely a high level of collaboration from the Developers you are working with.

Is this something unique to Software Testing or have you encountered this elsewhere?

When you hand over a deliverable to be tested at what point does your tester get that 1000 yard stare? I’m referring to that look in their eyes when they are in the middle of running test cases and no matter how professional, the repetitiveness overwhelms the eagerness to provide good test coverage.

Take a step back for a moment and imagine hovering over your Test Lab. Now look down.

  • Yes that’s your Server which all the virtual machines run off. It’s well set up, everything is up to date and it provides every configuration needed.
  • Over to your left are all the different Mobile devices for testing your app. Each one sitting in a cradle connected to it’s charger.
  • No shortage of whiteboards, your workstations are set up in an island, comfy chairs and even bowls of fruit and candy.
  • All those Agile tasks on the wall on your right .. Post-It Notes rock!
  • On that screen you can see your Defect Tracking; it’s the best your budget can buy. Well setup and managed by yours truly.
  • Your Test Case Management tool is open too on the adjacent screen. Just a moment..

From up there you can see things a bit clearer. Some of the things your testers have been mentioning about the Test Cases in the Daily Standup Meeting make sense now.

One of the smartest and most efficient things you can do with your test cases is structure the workflow!

image

We get infuriated by bad workflow in the products we test, thinking how it will bother the user and affect the UX for them. Did we stop and apply the same principle to our Test Cases.

Go the extra mile, sit down with your team at the planning phase and order those test cases logically; perhaps add an extra field to the Test Case Management tool that links a test case to another where it might have been implicitly run.

In a nutshell if you can order your test cases to maximize your efficiency. You probably will stave off that 1000 yard stare a bit longer, ensure better test coverage and more rapid progress.