Oakton DVS Agile

When I complete a project delivery, I like to make sure that I list the agile practices that were used to achieve this goal.

No matter what people tell you about agile, there is no one way to do it. I have delivered and managed many agile teams over the years and even the same team across multiple projects and I have never once seen exactly the same agile practices set used twice.

Just as fingerprints are different between individuals, so are agile practice sets for teams. The variables are so vast that no two will be the same, beit the product being built, the team and parts of its sum or the baggage we all carry from job to job.

This is normal and this is why I keep track of all the combinations as I go along.

In the case of the Document Verification Service that we built for the Commonwealth Government's Attorney General's Department, the picture above shows the practices and some of the tools we used.

It is grouped in to development, management and analysis (BA and QA together) practices. Some of course, overlap.

Always keep track of what worked and what didn't. Try them in your next project but don't force them. Sometimes the best practice on one team will die brutally on another and vice versa.

Just as agile allows projects to adjust with changing requirements, agile itself changes for its team requirements.

Rigour over rigidity, always.

Resume + Character is what I want

A resume does a good job of describing specific skills. Today I had lunch with a group from my last contract and then an evening of pampering with the women I work with in my current role.

Reference checks and resumes don't tell me how awesome you are as a person or why your ex-colleagues still love being around you. How do we judge a person's character when all we have is a list of jobs?

I think it's a combination of what is on paper and what you see in an interview. Let people reveal themselves face to face. Talk to people who know them. Look for character as well as a checklist of skills.

Why Organisational Culture Comes From the Top

When you are a doer, you want people to let you do your job and to help you improve at it. You need senior people who enable you.

When you are senior or a lead, you want people to let you do your job and to help people around you. At this point, you know how to improve yourself but you need to be allowed the space to grow and move.

When you are a team, group or organisational leader, you want people to let you do your job and to enable those around you to do their jobs. You want to aid in individual and organisational growth.

If one of these points in the hierarchy doesn't want to enable others and instead focuses on themselves with little to no regard towards those around them then organisational culture changes. In my opinion, it changes for the worse.

Too many places I have worked see leaders who see their career journey and their need to climb a corporate or financial ladder as more important than the people around them. When they finally achieve the power required to drive their own careers, they declare it "every man for themselves!" and start kissing up and kicking down. Or worse, they simply neglect their teams.

I asked a recent manager in a past job if he cared about his team at all and the dysfunction that was tearing his team apart. He said to me "I don't have time to care." At that point, I reached out to my network and found myself a new job.

You shouldn't work for a manager or leader or boss who doesn't have time to care about his or her team. Nothing good comes from that.

If you look above you in an organisation and don't see anyone caring about the people who work for them then leave. If you look around you and can find no allies who will fight for your team over themselves then leave. If you don't want to enable the people you work with or aren't allowed to then leave.

I once had a manager who told me to stop enabling people because it was getting in the way of them working. He also thought bums on seats was more important than productivity which ultimately drove his subordinates to avoid his desk to take coffee and toilet breaks so he wouldn't see them. He didn't want anyone to be allowed to grow and achieve in their roles. Instead, he wanted them to clock in and clock out and show him the appropriate amount of fear inspired respect. As you can imagine, his team ended up as toxic and broken as he was.

Organisational growth comes from its leaders. So does organisational rot.

If you can respect the leaders around you then you will like your job and where you work. If you can't get near them, don't know what they represent or purely dislike their ethos then you need to go somewhere else.

Organisations can not be healed from the bottom. They are shaped and scented from the top.

I was humble once and I was awesome at it or 5 Rules to Being a Great Team Lead

I often mock humility with my favourite saying "I was humble once and I was awesome at it."

The truth is that I think humility is a virtue. It is a moral excellence and one that many claim to possess but then fail miserably at.

The reason I bring it up in this context is because you can not enable and serve a team unless you possess the ability to put yourself last and not aspire to take the credit.

In the last few years, I have worked with egos that would sink the Titanic. Most have been brilliant individuals that for some reason craved the acknowledgement of their brilliance to sustain them.

There is one thing that I do well and it is building teams. That doesn't mean I am awesome at hiring geniuses. It doesn't mean I am great at finding combinations of people that work together. That doesn't mean my teams exist because of me. The one thing I do well is serve my teams. I exist to build a safe and sustaining environment that allows people to do their jobs.

People want to do good work. They want the 8 hours they spend every day to mean something. Most people don't want to run the world. In fact, they want that kind of rubbish to be kept out of their way so they can contribute to the best of their abilities.

I have five rules that I believe make a great team lead:

1. Lead from behind - enable your team to do what they do best. Don't pull them along by a collar;
2. Share the fame and share the blame - don't single anyone out as a hero or a villain. Teams produce great results, not individuals;
3. Celebrate all the wins, no matter the size - don't wait for external validation to celebrate your team. Make the little moments big moments and the big moments, amazing;
4. Lead the charge and die trying - always be part of delivery and contribute to success. No one will follow you if they don't think you truly understand what it is like to be them; and 
5. Have fun - life is too short to be serious all the time. There is a time for seriousness and that is usually with your clients. With your team, you should be a person who laughs or cries or falls flat on your face. Being real will allow people to be themselves and when they are themselves, they will be great.

Humility involves succeeding and failing. Both are valid. Failing is ok as long as you learn from it. Success is ok as long is it doesn't go to your head.

User Story with Technical Use Case Template

Every single time I join a new agile team, I am asked the same thing - How do you write a user story?

There are many ways to achieve this. Here is mine template of choice. It is a User Story with Technical Use Case template. The hardest part everyone has when writing a story is defining Business Value. If your users wouldn't say it then it isn't business value. Keep that in mind.

User Story: @id

User Story: [One line description of the story. Keep it short as this is how the team will refer to the story. e.g. Eligible User logs in]

As a/an [persona/user/role/consuming-system e.g. Eligible User]
I want to [do a function of the system e.g. Log in]
So that [business value e.g. Access my information]

Main Flow

Preconditions/Entry Criteria

• This is an unordered set of conditions that must be met before the first step can begin.
• E.g. The user is on the login page
• E.g. The user has already been added as a valid user with a username and password
• …

Steps
1.      This is an ordered numbered list of steps that represents the happy path through the workflow.
2.      E.g. User enteres username and password.
3.      E.g. User clicks the “Login” button.
4.      E.g. User is authenticated and authorised and shown the Successfully Logged In page.
5.      …

Post Conditions/Acceptance Criteria/Exit Criteria

• This is an unordered list of conditions that must be satisfied in order for the flow to be considered completed.
• E.g. User sees the Successfully Logged In page.  
• …

Alternate Flow 1

Preconditions/Entry Criteria

• This is an unordered set of conditions that must be met before the next step can begin.
• E.g. User login was unsuccessful
• …

Steps
4.1   This is an ordered numbered list of steps that represents the happy path through the workflow.
4.2   This included all error flow but not exception flow.
4.3   E.g. User sees the Login page with an unsuccessful message .
4.4   E.g. User is able to retry logging in.
4.5   …

Post Conditions/Acceptance Criteria/Exit Criteria

• This is an unordered list of conditions that must be met for the story to be complete.

Alternate Flow 2

 … 

Alternate Flow 3

… 

Exception Flow

Preconditions/Entry Criteria

• This is an unordered set of conditions that must be met before the next step can begin.
• E.g. A system exception has been thrown.
• …

Steps

• This is an ordered numbered list of steps that represents what happens every time there is an exception in the flow that can’t be anticipated. 
• E.g. User sees the Error page with an filtered error message
• …

Post Conditions/Acceptance Criteria/Exit Criteria

This is an unordered list of conditions that must be met for the story to be complete.

Top 3 Irrational Fears when Designing Web Sites for Mobiles

Over the last three years there has been an explosion of web development for apps being required to run in browsers on desktops, laptops, mobile and tablets. With the savvy user, moves to improved touch acceptance and further short attention spans, user interface design has changed.

Prior to the current climate, everyone wanted to direct users to their own native apps that would give a richer experience. It is now accepted that rich native apps are the domain of the user who has already committed to your brand, service or product. They have been using your online or offline business for a while and now want quick and continuous access to you.

It is not often the case that users are won over to loyalty and consistent use to mobile apps unless there is a gimmick, game or hardware specific reason for the uptake.

A lot of people are using the browsers on their phones and tablets, in the same way that they use the browser on their laptop or even more retro desktop machine.

This means that every web developer must be aware that they are designing their apps for users who will browse them on multiple platforms, in multiple browsers and with very little momentary predictability.

With this in mind, developers are freaking out about what good web site design means. With that panic comes fear of moving from old web design habits based in skeuomorphic principles to newer interactive flat designs.

When I work with people to build multi-view web applications (usually in ASP.NET MVC), I make an effort to beat out of them their top 3 irrational fears.


Mobile over Everything
No matter what you tell yourself or how much you want to believe that people lounge in front of their laptops on the couch at home using your web site, you will have to come to accept that the majority of people will view your site on a mobile device.

If this isn't in the case right now then it will be absolute within the next year. People use their phones to check the weather instead of walking outside. People use their phones to access social media before they roll over and kiss their partner good morning. People judge your web site by the way it looks in their mobile browser.

You don't want to fail at this step. Don't be afraid though, this like everything else in our profession is a solved problem.


Scrolling over Pages
As touch interaction becomes more useable with newer mobile phones, tablets and touch enabled laptops and monitors people are more inclined to click on links on websites. However, this is more usable in higher resolutions and not always so friendly in the phone space where you sometimes feel like you are bashing the screen with your gorilla fist.

With that in mind, the rule of never scrolling that we were taught at the start of Web 2.0 is no more. Scrolling is what people do without hesitation or irritation on mobile devices. It is an opposable thumb swipe that behaves exactly as they expect without the concerted effort of clicking a link between two other links that might not be the one you meant to click.

Stick with the rule of scrolling in one direction and you will have happy users. Never scroll in two directions because it jolts the user in to having to work out if where they are going and what they are doing. One dimension only.

Always choose to put more information on a screen and let it be scrolled rather than asking the user to page.


Minimalism over Sensory Overload
Flat design is the word of the moment, although it has been around and had requests for seconds since well before iOS7. Even Microsoft pushed for minimalism in Visual Studio 2012 onwards, to the astonishment and even disgust of some devs.

Developers, especially front-end focussed ones, still tend to lean towards bringing the richness of dedicated clients to the web. Instead, the current trend is to bring usability and simplicity to the web so that mobile users are not fighting the animations and over-populated screens to get what they want done.

If you can make it simple then do. No one is impressed with the equivalent of a 1997 HTML blink tag when they can look at a clean screen and find what they want with not too much mental effort.


Remember those three guiding principles and you can start moving in the right direction, if you aren't already thinking this way.

Define Done

Often when I read blog posts or articles about agile, they are talking about advanced concepts or solving funky problems that happen when you're in the depths of running an agile team.

The alternative are Masters of whatever flavour of agile is in at the moment. They are saying you start by following these exact rules that will save your whole team. I call bullshit on all of them.

In a previous post, I spoke about how there is no point is applying an agile band-aid if you don't work out where you are first and then add rigour to your current processes.

Once you do work out what practices your team is using and identify them and apply rigour, it is time to start putting in place some entry and exit criteria to initiate work and define success. I consider it drawing two lines in the sand that represent where we start and where we finish.

I always start with multiple Definitions of Done that apply to sprint tasks/stories, the entire sprint/iteration and the project.

This gives the whole team an idea of what it means to have completed a task and signed it off. That doesn't mean you comply with full continuous deployment and produce production releases at the end of each sprint (although we all dream of such a utopia) but it does mean that you have an end state that is achievable and universally understood. Working software is of course, part of this end goal.

It is important that this is understood before you even start the project so get this in place and get buy-in before you seriously put in any delivery effort.

Definition of Done for a User Story
I often treat the definition of done for a user story as the exit criteria for the swim lanes on a Kanban board. This defines when a user story that fits in a sprint is considered complete:

• Business analysis is complete [Owner: Business Analyst][Swim lane: In Analysis];
• Technical analysis is complete [Owner: Technical Lead][Swim lane: Ready for Dev];
• Estimation of effort [Owner: Entire delivery team][Swim lane: Ready for Dev];
• Implementation of the user story is complete [Owner: Developer][Swim lane: In Dev];
• Implementation of unit and integration tests [Owner: Developer][Swim lane: In Dev];
• Integration with all other sprint stories [Owner: Developer via Continuous Integration][Swim lane: In Dev];
• Automated packaging [ Owner: Developer][Swim lane: In Dev];
• Automated or manual deployment [Owner: Developer and Tester][Swim lane: Ready for Test];
• Full functional testing in a partially integrated environment where mocks are allowed [Owner: Tester][Swim lane: In Test];
• Sign-off of user story functionality, confirming implementation reconciles to requirements [Owner: Tester][Swim lane: Ready for Sign-Off]; and
• Sign-off from product owner that the user story has been delivered [Owner: Product Owner][Swim lane: Signed Off]

Definition of Done for a Sprint

A sprint is considered done when:

• Sprint planning was run and included the whole team;
• All user stories are signed-off by business;
• All user stories have been fully integrated with the current working software;
• Automated test coverage meets the agreed team standard;
• A retrospective has been run and actions owned or implemented by owners;
• Backlog has been groomed for future sprints;
• A deployable package has been prepared and versioned for release to an acceptance environment (that may be production); and
• Actual versus Estimated Velocity has been compared for future planning.

Definition of Done for a Project

This is a much tougher one. It depends on the situation you are in and the environment. Often we aim for working software and successfully full requirements reconciliation. There are many other things though that make this list. It is one that must be agreed to prior to delivering the project.

The important thing about any definition of done is that you must know up front what the goal posts are defined to be and not move them. Yes, you can change the way you play the game but you still know what it means to be finished.

Don't start until you know what it means to finish.

Don't Be A Jerk

In 2006, Joel Spolsky wrote a revealing blog post about how his company FogBugz hired staff. There were a lot of great insights about having strong firing policies to match your hiring policies.

He talked about technical skill and all sorts of stuff but the one thing that stuck with me was one line that reinforced my view of the world and myself: " Even before we started the company, we realized that we should add a third rule: 'Not a jerk.' "

I have worked with thousands of people now as a contractor, consultant and researcher.

Through the years, I have seen people who I would quite willingly call genius. Brilliant beyond what us mere mortals can call smart. Above the intellect of the most intellectual intellectuals. I am not one of them. They are often so aloft when it comes to perception that the rest of us look like ants on the dirt.

The thing is that I have also worked with very smart people. Not someone to be tagged with genius but very smart. Architects. ThoughtWorkers. Just smart people.

Over and over again, I have come to one conclusion when I build teams. I don't want to work with jerks. No matter how smart you are. No matter your skills or your gansta gains, there is nothing that would make me pick a pretty good team player with above average skills over genius who solved everything.

The way I see it, if I have to be stuck on a desert island with you forever building a hut or a raft or cooking the same old fish and bark we have eaten for months then I want to like you.

We are but people. We want to want to be at work if we must. If there are 40 hours of our 112 waking moments then I want to volunteer to be there with others.

Nice people make that possible.

What Joel was saying in his vast wisdom is that you have to choose good people but they have to be good people. I'd forgo your brilliance for someone who can gel with the group. I'd give up that insight for someone who was above good but liked people. And if you don't get that then you shouldn't come work with me.

Mean people are blockers.

Hire good people who get shit done and aren't jerks.

Forget Being Lean Until You Get Some Rigour

Over and over again, people talk about Lean like it is a giant waterproof, super-fast healing Band-Aid that will fix every delivery team. They say "Toyota this" and "Motorola that" and "you're not lean enough."

The problem I have with this is when the Band-Aid is being applied to a delivery team that has no structure at all. You can't make a cowboy team leaner or even more agile without putting structure in place and then improving it.

I don't mean picking Scrum or Kanban and saying do this and then become leaner. Instead, I mean that teams must become aware of their as-is way of functioning. Identify practices and articulate them. There always are practices in place but people are not always conscious of them. Without consciousness, there is no method. Once you have method, you can use it rigourously.

Become aware of what you do now. Decide on where you want to be. Map a course of action from one to the other and most importantly, give yourself time and give yourself permission to fail and correct.

Telling a team with no self-awareness to become leaner is pointless. First find the point.

Agile - Is it only mostly dead?

One of the fathers of the Agile Manifesto, Dave Thomas (@pragdave) wrote a blog post a couple of weeks ago proclaiming that "Agile Is Dead (Long Live Agility)."

The post has been moving through the software dev community and causing much head nodding. Everyone seems to agree that the word "agile" means very little these days and has been corrupted by the trainers who will make you a Master from a two day training course for thousands of dollars.

At ThoughtWorks, we would mostly snigger at people who called themselves Scrum Masters but not because they were so quickly empowered. It was more because they missed the point of being agile and instead adopted prescriptive processes and accompanying costly tools to achieve what can be done with much less and achieve much more.

The reason that I am happy Prag Dave spoke out and voiced this is because people will hear it now.

Being agile is a way of thinking and acting and not a set of hard and fast rules that make better software. Tools and processes won't save a team. Pragmatism, rigour and constant feedback with change will.

I don't know if the word "agile" is dead. The good thing is that a lot of us agree that we need to be more agile and not do agile.

So go do that already.