Posts tagged Point2

Constant improvement is a Team Sport

We focus pretty heavily on constant improvement here at Point2.  Improving our company, improving our departments, improving our teams, as well as individual improvement.  There are many things that we do well at the team and department levels, but they don’t always filter all the way down to the individual level.

The first thing to recognize is that while the desire to improve is a great first step, it doesn’t amount to anything unless you translate that desire in to action.  There are many different ways to do this, so i’m just going to stick with my favorites at the moment.  I generally hear people give the advice that you should write down your goals because it increases the likelihood that you will follow through.  Writing it down is a good first step, it forces you to accurately articulate what you are trying to do.  However, just writing it down isn’t enough motivation if you ask me.  If you really want to make the improvement, you need to tell people what you’re trying to do.

Trust your peers. They care about you and your improvement!  (if they don’t, find a new job!)  Telling your peers what you are currently trying to improve on will greatly increase your chances of success for two primary reasons.

The first reason is simply that you won’t want to let your peers down.  When you tell your team that you are trying to achieve a goal, they want to see you achieve it.  If you work on a great team that promotes improvement, you’re team now has a vested interest in seeing you make your desired improvements and reach your goals.  You’ll be much less likely to give up or procrastinate while they’re watching your progress.

This leads directly to the second reason telling your peers about your desired improvements and goals is beneficial.  As I said, they care about your improvement, and they have a vested interest in seeing you succeed, so they will HELP YOU.  All too often, people try to make improvements and reach goals in a vacuum.  You work for the team, let the team also work for you.

There is no medal or gold star for making an improvement solo without any outside help.

By: Chris Dagenais

Leave a comment »

Value AND Velocity!

In last week’s post I talked about how a stakeholder can use Value Points as a useful metric, and how to assign Value Points to epics.  Value Points are good for determining whether the team is working on the right projects but they don’t paint the entire picture.  This is where Velocity points come in.

At Point2, we estimate story sizes based on relative complexity.  The simplest thing we can do is a 1, something about twice as difficult a 2, and so on.  Some people prefer time estimates, either method of sizing stories is fine here.

Once you have both Value and Size estimates for your stories, you can plot them on a scatter plot.  Here I plotted story size on the X axis, and Value on the Y axis.  Small size, high value stories are in the upper left quadrant, low value, large size stories are in the lower right.  In this example, I would probably get the team to do all but 3 of these stories, those being the ones with size 5, value 2 and 3, and size 3, value 1.

scatterplot

The interaction between value and size is an excellent way to make sure your team is delivering the right product.  High value, low complexity stories are great for delivering some quick value, possibly as a means of generating the capital to tackle the larger projects.  Low value, high complexity stories might be best left on the shelf, or alternate means of solving the problem sought.

By: Tefon Obchansky

Leave a comment »

Blitz Planning at Point2

One session that I attended in Chicago at Agile 2009, and thoroughly enjoyed, was Alistair Cockburn’s Blitz Planning workshop.  First, Alistair is an engaging speaker and is full of great ideas.  Second, it was the last day of the conference and I was eager to start trying some of these new tricks, tips and techniques I’ve learned about all week at home at Point2.

Blitz Planning results in “getting the contents of everyone’s head into a common space” and is meant to be speedy.  In the 90-minute workshop we planned a non-technical workflow (the process of getting up in the morning and getting out the door), then we planned an information kiosk system start-to-finish, and identified the earliest we could do the initial rollout.

blitzplanning1

Ideas are recorded on index cards by all members of the team as they come to mind and are not subject to scrutiny by other team members.  As a team member writes on a card, they call out their idea to help avoid duplication, and to spark more ideas from other team members.  When the team feels the plan is near complete, the cards are laid out on a table in chronological order, the plan is checked for completeness and any dependencies are identified.  At this time cards may be torn up, and more cards may be written to fill the holes in the plan or re-work it to remove dependencies and shorten the critical path to allow early delivery.  Alistair introduced the concepts of the “technical walking skeleton” and the “business walking skeleton” which contain the bare minimum to make it work, and the bare minimum to provide business value, respectively.  Your earliest possible delivery consists of both the technical and the business walking skeletons.

Unlike the information kiosk example at the conference, the project we planned touches existing systems and contains many moving parts.  Instead of 20-30 minutes to design a system and discuss it, we took an afternoon to write the cards and discuss, and we have more discussions and card-shuffling sessions planned for the next few days.  So far it’s been an interesting exercise and I feel like we’ve identified several potential problems early.  I’ll keep you posted.

By: Tefon Obchansky

Comments (2) »

Getting Agile in the Windy City

With Point2’s plunge into Agile and Scrum eighteen months ago, things have really started to take shape here. Teams are self-organizing, modifying process and practices, collaborating, delivering what the business actually wants….and the list goes on. And with Point2’s culture being that of learning, things will just continue to progress – we’re always concentrating on getting better at what we do – writing software.

This year Agile 2009 is being held in Chicago, Illinois (August 24th – August 28) and we’re sending four representatives to soak up all of the information they can, while also spreading the word about Point2. For those of you unfamiliar with this conference, here’s a quick blurb from their site.

Agile 2009 will be an exciting international conference about techniques and technologies, attitudes and policies, research and first-hand experience, from both the management and technical sides of agile software development. The agile approach focuses on delivering business value early in the project lifetime and being able to incorporate emergent requirements. It accentuates the use of rich, informal communication channels and frequent delivery of running, tested systems, while attending to the human component of software development.

It looks like the conference has a large focus on leadership, coaching, and business analysis techniques so we tried to fashion the Point2 contingent appropriately.

Ryan Shuya is a Consultant on our heavy equipment team and is always trying to find better ways to manage our long distance relationship with Caterpillar. Lucky for us Agile 2009 is offering a number of sessions on distributed agile.

Tefon Obchansky is a Business Analyst on one of our development teams, and is always looking for better ways to write stories, breakdown work, and make sure the business is being represented accurately. Tefon will be hitting up as many BA centric sessions as possible with the intention of passing on his experience to the entire BA team at Point2.

Dustin Bartlett and yours truly are both Team Leads on a couple of our development teams. We are always trying to muster up ways to get our teams to run more efficiently, while still holding true to the Agile principles. Dustin and I will be spreading ourselves across a lot of the leadership and coaching sessions with hopes of bringing back new ideas to Point2.

So while you’re in Chicago watch out for four guys wearing Point2 t-shirts. We’d love for you to come say “hi”. We’re a pretty talkative bunch so maybe we can exchange our experiences in the world of Agile and Scrum. Like I mentioned earlier, we are a culture of learning – and what better way than to learn from the experience of others.

By Hemant J. Naidu

Leave a comment »

The Corporate Culture of Post-it Notes

Ahh, the ubiquitous Post-It® Note.  My workspace is covered with lovely multi-coloured notes, or it was until I discovered Digital Notes. The unassuming Post-it has become a legend but I wanted to  share it again, as told in The Knowledge-Creating Company by Nonaka, and Takeuchi.

Knowledge_Creating_Company

“Art [Fry] sang in the church  choir and noticed that the slips of paper he inserted to mark selected hymns would fall out.  He decided to create a marker that would stick to the page but would peel off without damaging it.  He made use of a peel-able adhesive that Spence Silver at the Central Research Lab had developed four years previously, and made himself some prototypes of the self-attaching sheets of paper.

Sensing a market beyond just hymnal markers, Fry got permission to use a pilot plant and started working nights to develop a process for coating Silver’s adhesive on paper. When he was told that the machine he designed could take six months to make and cost a small fortune, he single-handledly built a crude version in his own basement overnight and brought it to work the next morning.  The machine worked.  But the marketing people did some surveys with potential customers, who said they didn’t feel the need for paper with a weak adhesive.  Fry said, “Even though I felt that there would be demand for the product, I didn’t know how to explain it in words.  Even if I found the words to explain, no one would understand…” Instead, Fry distributed samples within 3M and asked people to try them out.  The rest was history.  Post-it Notes became a sensation thanks to Art Fry’s entrepreneurial dedication and dogged persistence.

(Nonaka I, Takeuchi H. The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. 1995)

That entrepreneurial spirit has been part of 3M’s corporate culture almost since inception.  As stated in the William L. McKnight Management Principles:

“As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative. This requires considerable tolerance. Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way.

“Mistakes will be made. But if a person is essentially right, the mistakes he or she Post-itmakes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs.

“Management that is destructively critical when mistakes are made kills initiative. And it’s essential that we have many people with initiative if we are to continue to grow.”

Chris touched on this when he blogged about Failing Should be Easy and even Why don’t people like my ideas?!.  Art Fry was given the opportunity to fail.  When people didn’t like his idea, he proceeded to find a way to prove that his idea truly was great.

I’m proud that we here at Point2 allow people to fail; in fact, using Test Driven Development we ensure that everyone fails at first.

We give people time to explore and experiment, and everyone has some time for professional development.

Incidentally, Ken Schwaber’s early paper, “SCRUM Development Process” references heavily the work of Takeuchi and Nonaka and their description of a rugby organization style.

By: Kevin Bitinsky

Leave a comment »

Risk and Testing in Las Vegas

So, here I am in my hotel room, at the end of the second exhausting day of the Better Software Conference and Expo, in Las Vegas, Nevada.

Where to begin? The plane trip was good, the cab ride was terrifying, the Strip is unlike any place I’ve ever been. If you want more details about Vegas, send me a note, I’ll give you my full opinion. But let’s talk about software.

My first Tutorial was Ken Collier’s talk on Agile Modeling. Really useful stuff. I didn’t know exactly what I was jumping into here, so it was good to see that there was dialogue on a level I could participate in fully. Ken spoke well about the core principles of Agile Modeling, including the need to ‘travel light’ – no model will meet every need, so make the model that meets the particular needs of that stage in development. He went on to discuss domain modeling, architectural modeling, and usability modeling. He also gave a really useful run-through of use cases, use case personas, scenarios and user stories.

After that was Jeff Patton’s talk on User Story Mapping – building a better backlog. Jeff’s talk was good also – covering some of the same material as Ken did around user stories. One of the refreshing things about a conference like this is that you get to hear how different groups are using the same Agile methodologies. Or put another way, over dinner last night (a quiet little spot near the hotel that had slot machines right in the restaurant, imagine!) I remarked to Kevin that I’d heard two different definitions of a user story in the course of a single day.

One of Jeff’s excellent points was writing out a use case scenario and then making stories based on every verb in your scenario. This is a point that I as a Business Analyst sometimes miss – that we’re not trying to enable our users to be something, we’re enabling them to do things. This is one of those little shifts in approach that I know will make my work a lot easier when I get back home.

Today started with Julie Gardiner’s talk on risk-based testing. Immediately she explored how risk management involves three steps – identification, analysis and mitigation. She then walked us through four different approaches to risk management – the TMap approach, heuristic management, the STEP approach and an approach pioneered by Paul Gerrard. The latter was particularily enlightening, as it includes a means of factoring in existing testing capability as a means of prioritization. Definitely lots to take away.

As it was yesterday, lunch at the Venetian Hotel was a subdued and somewhat spartan affair. This place puts itself up as ‘The Italian Vegas Experience’ and yet, there was only one course of appetizers. Amateurs. You know what they say though – the problem with Italian food is that four or five days later, you’re hungry again. I couldn’t help but feel sorry, however, that I had to miss the Point2 Tuesday lunch meeting. Nobody back in Saskatoon ever gets after me for using the wrong fork. I guess I’m just homesick.

The high point of today, however, was Dan North’s presentation on Behaviour Driven Development. Really enlightening. A couple of points to consider – One is the simple point that we use all of these construction metaphors – builds, architecture et cetera – for an industry that’s inherently different and much, much younger. He summed it up with ‘The thing about software is, it’s soft. ‘ With that, he went on a fantastic rant (Now I know where Aidan gets it!) about moving towards a stakeholder-centric process that ensures just enough work to get just the right results.

…and yet another definition of what makes up a user story. As a conference participant I need a consistent definition of a user story so that I’ll know what the heck to put in my Jiras when I get home!

Well, I’m off. The sun has set on the Strip as I write this. If you’re in Vegas, look us up – we’re at the Imperial Palace. Kevin’s the one with the cane and the feather boa at the craps table. I’m the one writing the blog posts.

Heh.

By: Dave Kellow

Comments (1) »

Why don’t people like my ideas?!

frustration1 Have you found yourself asking that question?  I’m sure many developers have, although this topic applies universally to anybody in any profession (or personal life for that matter).

http://agileshoptalk.wordpress.com/2009/06/09/why-dont-people-like-my-ideas/

By: Chris Dagenais

Comments (1) »

Mocks, Stubs and Spies! Oh my!

I’ve been pretty involved in helping out new developers at Point2.  I try to ease them in to our agile, Scrum/XP environment easily, but there are usually a few roadblocks.  So far, the most troublesome obstacle has been the use of Test Doubles.  To try and mitigate this a bit I’ve written a 3-part series on this topic.

Part I is on stubs.

Part II is about mocks.

Part III covers spies.

Enjoy!

By: Kevin Baribeau

Leave a comment »

Failing Should Be Easy

failSounds kind of crazy doesn’t it?  Why would you want failing to be easy?  There’s actually a pretty simple explanation.

http://agileshoptalk.wordpress.com/2009/05/14/failing-should-be-easy/

By: Chris Dagenais

Comments (2) »

Why Pairing is Better

My wife and I plan our finances each month. We look at how much we spent in the previous month and why, and we project what we will spend in the upcoming month. It’s pretty lo-fi: A 20 column ledger and a spreadsheet. The ledger is always lying out and open so we can write in it as soon as we get home.

The spreadsheet is for calculations and planning. At regular intervals we sit down together, Wendy and I armed with our favorite tools. She relays the numbers from the ledger and I enter them into the spreadsheet. Wendy is focused on reading and relaying the numbers while I am focused on data entry. Once the numbers are in we quickly double-check just to be sure. The process takes less than 5 minutes for 40 – 60 entries.

This time Wendy did the data entry on her own. I asked how last month looked and she said “We spent a lot on groceries”. I happen to like eating so it’s not a big deal that we overspent, but it’s still nice to know why it happened. There is always a reasonable explanation. Meat is a major portion of the bill, and maybe we bought too many bags of frozen peas. Or maybe there is a mistake in the data.

Had we paired during the data entry we would have been assured that the entry was in fact correct and we could begin a meaningful analysis of our overspend. I am now forced to look back through the data in the ledger and ensure that it has been entered correctly. This will take more time because I will be switching tasks many times:

  1. Find the entry in the ledger
  2. Remember the value of the entry
  3. Move eyes from paper to spreadsheet
  4. Scan to find the corresponding entry in the spreadsheet
  5. Recall the value of the entry
  6. Verify the values

Compare these steps with those that I would do when pairing:

  1. Translate what Wendy said
  2. Verify that the value she relayed is correct in the spreadsheet

Yep, only 2 steps. I don’t have to keep switching focus from paper to monitor, nor must I remember any values. I just verify that the value she gave me is the value in the spreadsheet.

When I sat down to verify our numbers, the realization that pairing is much more effective (and arguably more efficient) hit me like a ton of spaghetti code. When you are working on complex tasks you are forced to make switches between contexts – the problem and the solution details. In my example the problem is incorrectly entered data, and the details are moving my eyes from paper to screen, then remembering and verifying values. When writing code the problem is the bug/story you are playing, and the details are language syntax, editor shortcuts, etc.

Now to the point. Imagine that you could offload one of the contexts and fully focus on the other. Wendy can focus on the problem (relaying the numbers) and I can focus on the details (data entry). When writing code the navigator is focused on the problem (satisfying acceptance criteria and design) while the driver is focused on technical details (syntax, shortcuts, stubs, tests…). It stands to reason that pairing prevents mistakes due to context switching, thus solving problems more thoroughly and with fewer mistakes.

P.S. – I asked Wendy to pair with me on the verification. Next time I won’t be so lazy and I’ll help her do the data entry in the first place :)

By: Ryan Shuya

Leave a comment »