Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts

Friday, July 13, 2018

Introducing: "SWARMing"

Hello all! I popped into Dan North's blog to see what he's been writing about lately. Dan North introduced BDD (Behavior-Driven Development) to the world which bridged a huge gap between the Customer and the Team.

His latest post "In Praise Of SWARMing" grabbed my attention. I thought it was going to be about "swarming" a problem as in Kanban. But it's actually a different-ish approach to adopting Agile at Scale. SWARMing is Scaling Without A Religious Methodology.

His ideas really hit home with some great points! There are some harsh criticisms of competing methodologies. Those are somewhat tasteful. And I have to warn you, its a bit wordy. At over 4200 words, it's quite a bit more than your average "browsing the internet" post.

Here are some things that really jumped out at me.

The Good Parts

I particularly like the contrast between "moving the work to the people" and "moving the people to the work." This translates to reorganizing. The term "self-organizing teams" comes to mind.

I do prefer the flat structure of "every part of the org is geared in delivering value" vs the slanted structure of "sales makes the money and everyone else spends it." It allows businesses to utilize all their assets in focus of value delivery.

I read once that value is expressed as the benefit for the cost. A "good value" doesn't necessarily mean inexpensive. It means you actually got a return on your investment, monetary or otherwise. I wonder if looking at your organization from a "good value" perspective would make a positive difference.

Speaking if value: There are a couple terms worth following up on. OKRs are a relatively new way to set and measure goals. I learned about Risk-Adjusted Return on Investment, which is your profit plus or minus risk.

The Bad Parts

The post is long. It has quite a few run-on sentences. The upshot is that it's not an easy read. My concerns are that you (dear reader) won't see through to the beneficial parts. Please press on, it's worth it!

You've also got to see past the sales-y aspects. He's pretty tough on competing methods of implementing Agile at scale. He's right with those points, but it drags the article and makes for a slightly bitter taste. Sorry.

I get it, he's selling consulting services and differentiating from his competitors. But that wouldn't really be necessary if the most valuable points were laid out without the cruft. Maybe do those parts in a future post dedicated to a comparison.

The last "bad part" is the focus on hard numbers. These days, organizational psychology says to keep your focus on doing good for your customers. But that depends on perspective I suppose. Those with the pocketbook will care about the revenue aspect, especially when they're being told to rethink how they allocate funds!

The Rest

Somewhere past halfway, Dan iterates over eight points about how to be SWARMing. Some of those go into depth with definitions of types of leaders: servant-leader and leader-leader. This section has some practical advice for hiring services to help with your transformation process. The successful transformation will be a long and investment-intensive road, so buckle up!


I sent Dan an email asking if he had a more concise description of SWARMing. One that, hopefully, lays it out without the heavy padding. Those things are valuable to support the idea, no doubt! But I can't exactly expect busy execs to read such a lengthy argument all at once. Especially when it's a new idea which asks them to rethink their organization from top-to-bottom, front-to-back, and side-to-side.

All in all, I'd say it's worth taking the time to read his post. With the right packaging SWARMing could be a catalyst for much needed change. I hope it gets that with a bow on top.

Wednesday, February 21, 2018

What a Story! An Agile Story

You've heard of this thing called a User Story right? Perhaps you've even seen the template:

"As a <type of user>,
 I want <some feature>
 So that <some goal>."

But perhaps you've wondered how to put a feature like "read the users name from the database and put the value in txtbxUserName" into that format.

Occasionally, I write about Agile on this blog. In that entry, I wrote about a broader view of Agile from a developer perspective. In this one, I made a case for leaving the work up to the pros. This time I'm focusing on something much narrower — the User Story.

The Wrong Way

Perhaps not "wrong" way, just not something that's going to align very well with the benefits of Agile.

"As the one telling you how to do your job, I need you to write code that reads the username from the Users table and put that value in the txtbxUserName field so that it shows up on the page".

Or perhaps "as the project sponsor, I want a check box there so the users have to check the box before they can submit the page."

It can be a bit awkward to put those kinds of instructions into User Story format...especially when the goal is not for the user but for the project sponsor or manager to tell a developer what to do. You can succeed at writing good user stories if you frame them in more general terms — don't think about implementation details. A good test is — if it's awkward it isn't right.

Maybe Better

"As a user with access to multiple user accounts, I want to know who I'm logged in as so I know which account I'm using at any given time."

"As the company's legal counsel, I want the user to accept responsibility for using our services so that we have a leg to stand on if something goes wrong." That's the "I have read and understand the 30,000 words of legalese" checkbox.

Real Life Example

For another look, let's imagine were doing some work for a burger joint where their customers expect one thing — getting their food quickly. They want to order quickly and they want everyone else to do the same so the whole thing can flow like clockwork and they can be on their way to consuming those cals in under 5 minutes.

What does that story look like? Actually it may be helpful to have multiple User Stories since there are multiple user types or personas. Let's see about defining those now:

Regular Customer - knows what they want and orders the same thing all the time.

Infrequent Customer - didn't visit much and needs a minute.

Bulk-Orderer (team mom) - is ordering for the office or a party and has a bunch of items to order.

A story from each persona might look like this:

"As a regular customer, I want to place my usual order and get on my way so that I don't have to hassle with getting my food."

"As an infrequent customer, I want to take my time browsing the menu so that I can figure out what I want to order."

"As a bulk-orderer, I want to place my order without confusion so everyone gets what they wanted."

We're going to need a lot of cheeseburgers to feed that many Air-Force Cadets!
Who ordered no onions?

Next Steps

Now that we see the user stories in a more "user-need-goal" format, we can start to think through different ways to resolve the issue. That part of the process is a conversation. A conversation between the team and the customer.

That's a Wrap...(for now)

In this entry, we've seen how we van write User Stories from the perspective of the users, through different user personas. I haven't captured all of them and that's inevitable. The magic is that as we start rolling out features to support the users based on their stories, related stories will filter in.

You may have heard a little about different roles such as Team Member and Customer — especially about who plays which roles. We'll take a look at how that works in the next entry — there are some things to think about depending on your organization.

Thursday, November 16, 2017

Culture of Interactions

The Agile Manifesto puts the value of "individuals and interactions over processes and tools". Meaning that a conversation is where the work starts. Meaning that if your processes/tools are getting in the way of human interaction then you aren't practicing this value and not getting the benefits of Agile. For example, work requests delivered long-form via email is not an interactive process.

Agile processes generally use User Stories as a starting point for any development work. Just what is a User Story? It's really a placeholder for a conversation, no details except a concise introduction of the user's goal - "As an end-user, I want to print my essay so that I can mark it up with red-ink and make revisions based on the markup." This is the user's perspective. It isn't even about the user story, it's really just there to keep track of something.

As a technologist, I might want to poo-poo the idea of printing and using ink...or even wasting paper as an environmentalist...but this user story is her story, not mine. Through conversation, there may be a change of heart, but that comes into the fold of negotiations.

Through the initial conversation, we should come up with some Acceptance Criteria. It's documented, but not written in stone - it's just a first pass. It should be fairly basic and relatively quick to implement. May not be complete yet, but could be. The Acceptance Criteria is also known as the Acceptance Test...User Test...Story Test. It should describe how the user would validate the implementation (then we automate it, but that's for another time).

"When I click a print button, the essay should print. I should be able to go to my printer and get the printed essay from the printer. All pages should be there."

What can go wrong there? If have any experience with printers, we know there are too many ways that can fail! Printer out of ink, paper, jammed, just not having it that day, not connected, off. Computer/OS not happy with printer config, dialog comes up before printing, not connected to network. Network failure. Mercury in retrograde.

Perhaps in some future world, printing will just work, but for now we need to revise the Acceptance Test...that's why we need to work on it together...

"I can't promise the essay will print, but I can make it so that there's a print button which will tell your computer to print all pages of the essay to the default printer, or I can have it launch the print dialog."

There's some negotiation. There's supposed to be, it's another Value. But first, we should try the simplest thing that whatever the OS does when you want to print. And that just might get the job done.

Without the conversation, we'd have wasted half the project schedule on documenting something that was nearly impossible and then attempting to implement something that was doomed to fail least when Mercury isn't playing nice!

Wednesday, August 16, 2017

Where to Begin the Agile Project

So, your a programmer and you get a new project to work on. And let's assume this project involves some data source(s), probably some persistence, and user interaction. How do we approach the construction of this system?

In the first place, we'll want to understand what the system needs to do and what it will generally "look like". When I say look like, I mean how it will generally be architected - how does the data flow? What layers? What components? Where do they interface? This involves some basic design and there are several patterns to draw from that would get the job done.

Either way you design the general structure of the system, you'll need to understand the data flow. You'll be presenting some data to a user and that data will come from somewhere. It seems obvious that the first step is to begin where the data flow starts...begin at the beginning. However, I say NO!

Through years of trials and errors of beginning at the beginning, I've found that you generally have to change things near the data source at least a few times throughout the life of an "Agile" project.

I've spent much time modeling databases and building data layers for applications only find that once the front-end was built on top, the data model had some fundamental flaws. The main trouble is that those flaws only came out when the business stakeholders were able to interact with the system - when they were working with something concrete. Only then did the details truly solidify. But by then, there were layers built up below the presentation layer - interfaces, implementations, tests - that all needed to change to support this new understanding. This leads to much rework!

If we can have a better understanding of the system before there is a full foundation baked into the system, then we can reduce the amount of wasteful rework on a project.

To solve for this problem, we have some options. We can build wireframes and prototypes in a Design Sprint. This sort of design-up-front is useful in as much as our understanding of the system is complete at the beginning of the project. If there is a good general understanding by the requester, it will be relatively more useful to do mockups - it may trigger insight and understanding earlier in the "Agile" project. It's a way of saying "if I were to build this, would it solve your problem?" I'm for it and it does a lot of good, but it's not where we should end the game!

Another technique I like to use, and I'm urging you to do the same, is to "start at the end"! By starting at the end - meaning the desired outcome of the feature we're building this cycle - we can set some concrete earlier in the sprint (preferably on Day 1 - Sprint Planning). If you're building an analysis system, start with the graphs and charts. Mock up the data that feeds them. Then build backwards from there. It's best to find out how the system will provide value. Is it an invoicing system? Start with the invoice itself! Work back to entering the billing info.

When we do this - and it doesn't have to look perfectly pretty yet - we give the business stakeholder something to interact with BEFORE we build up all the supporting layers underneath it and put on the fresh coat of paint. It's like building a custom bike starting with the seat and handlebars first...then you put on the wheels and a temporary engine to test the rake of the front forks, footpegs, shifter, grips, brake levers, etc...the user interface. Then they know it's built to what they need - after all it is a custom!

But software is a bit different than building a hog. Users can't see or feel the engine directly. They interact through whatever UI you put on there - there can be mockups and design drawings and diagrams, but it's the concretion that will have the most meaning. Besides, mockups are throwaway - waste. You can build a mockup with the actual code, it's easy these days to get a basic UI up and running quickly. Better to build the real thing then iterate from there one little manageable decision at a time. Better to have to refactor early in one layer than have to chase a change up the whole stack!

Thursday, July 13, 2017

Managing Complexity in Today's World

Are business problems more complex today? That's the assumption I'm going to operate on - and I'm sure you'll find no shortage of sources on the web to back that up (empirical evidence aside). So let's assume that rhetoric for now in good faith and an appeal to common sense. Padding aside, that complexity flows through to the systems we create - the software included. In order to manage that complexity, we've become Agile.

I hear ya: "Not another article about Agile...". I know, I know.

But let me at least tell the story about what inspired this and then move on to the point. An IT professional (non-technical) and I started chatting and the conversation led to tools for automating business processes. I've developed on platforms and developed custom solutions for business process automation. Evaluating solutions can be a complex process in and of itself. The analysis process is fraught with uncertainty, broad (inaccurate) estimation, bias, and difficult to predict outcomes. Marketing (being what it is) definitely can skew the analysis. Heck, that's part of the duty of marketing! With proper marketing, sales is nothing but finalizing the deal that was already done through the marketing. So what does that have to do with Agile?

Agile is about being able to respond to change. In software, if we are truly following Agile principles and the practices set forth by the minds that solidified the movement, then we are designing and developing software that can respond to changes in the face of complexity. Lately, that seems to be the mantra of the business world as well - business needs to be Agile so that it can respond to changes in the complex market. As technology and automation have been evolving exponentially, so evolves the need for business to evolve to respond to those - among many other - changes.

Thinking about what this means in terms of managing change in the face of complexity and cost. In the software world, cloud computing has become all-the-rage for just those reasons. In the cloud, you pay only for what you use; changing and configuring resources is relatively easy; there are no data centers or servers for the business to manage. Good software design has been about responding to change for many many years, but now the infrastructure has caught up. It is a service rather than an internal resource.

Back to the topic of deciding on a platform...

Some platforms follow the cloud model - pay for what you use. Others - pay a big fee up front along with licensing and maintenance fees annually. Some platforms can respond to change - they are testable, debug-able, manageable. Others...not so much. Some platforms can handle some business situations easily. Usefulness is a function of cost v realization of value - as always, use the right tools for the job.

But whom should decide what the right tools are?

When you take your car to a mechanic - you may be paying for the service and it may be your car, but the mechanic knows which tools to use. Same with the surgeon, plumber, accountant, attorney, chef, construction company, or any other number of service professionals. Why should it be any different for software? Professionals know their craft. Business people know their business - and many know how to do software, woodworking, plumbing, some things legal, accounting, have dissected a frog - does that mean they should perform surgery? If you've replaced the float in the toilet, should you be replacing your own stack*? So who should decide which tools to apply in software development? Logically, it should be the professional software developer who knows their craft.

However, the situation changes when the cost exceeds the budget of the development department. Other levels of the business has to get involved in the decisions, there are politics at play, the tool may be oversold - then what? Now you've bought a tool without a use! So then you look for ways to use the tool to realize it's it's the non-tool user calling the shots (since they've put their money and reputation on the line) on which tools to use to do the job. Then partitioning of tool users happens - you have experts in such platforms. Someone higher up the food chain now decides which tool to use and assigns the problem to the expert(s) of that tool. The expert dutifully applies said tool to the problem (which of course is a problem that tool was designed to handle because when you only know how to use hammer, every problem is a nail).

What's the better model? Maybe that's better left to another post, but I'll give you a hint - there's no 01001001 in the solution.

*A stack is an air vent that allows the toilet to flush properly among other things; without it the suction would be a serious problem. Perhaps it gets blocked by leaves or a birds nest and you have some issues. They used to make them out of cast iron which is some really heavy stuff that can maim you if you don't know what you're doing. They've also used galvanized steel which rusts over time. That rust can also clog the stack. Replacement should be done by a professional only (no user serviceable parts inside).

Friday, April 21, 2017

Beyond Kanban

In the last lesson learned, we saw that Kanban is easy. It's easy because it only describes how work flows - there's a whole depth to it with value stream mapping, prediction, planning and measurement but that's really not that complicated either as we'll see soon enough. What Kanban cannot solve is how the work is understood.

In manufacturing, the origins of the culture that spawned Kanban, the product is always the same...therefore (much like a McDonald's) there are finite, well defined steps that procude a specified outcome everytime (within some degree of acceptance). In software, there's the same sort of problem but the product is different every time...

Since the product is different every time (if it wasn't we wouldn't need to build something new) the "specified" differs every time as does the "acceptance" and the "degree". Stephen Connolly eloquently describes this issue in this blog post

As Stephen describes by way of the problem with the shields on the USS Enterprise, the understanding of the feature will need to be clarified with the upstream party. Add a button to the screen, make it do something. Also make sure shields can be activated in other ways - different interfaces. the upstream party - shield system engineers (Scotty?) needs to make sure those shields can be activated from multiple sources. Now the shield becomes downstream for the activation call. Shield engineer specifies interaction protocols maybe defines some security practices - who makes that decision? Now it might be a deeper matter of verifying who is calling to raise the it Borg Captain Picard? Real Captain Picard? What's the override protocol? Does it need to change for this? Now it gets complex...what was a button is now a security and safety concern since were opening up access to a critical safety system...

Guess what? This is what Lean Change Management is all about - managing this sort of change without invoking filibuster (or bike-shedding, if you will). Map impact of the change, radiate change info, talk to people about the change, make changes small so they succeed. But I digress...

Point is, when we go beyond the initial ask (the happy path) and we have different requirements for each change, as Stephen points out, things need to be explicit. Kanban doesn't specify how this is done in software, but other processes do - to a degree.

In TPS (Toyota Production System) all the details are worked out well before the manufacturing process starts. In Software, that's generally not a good way to work. I recommend taking a bit from Scrum and breaking down the details at the start of some Kanban there is no iteration, but there is a work week so why not use that? Start going through the feature stack each week start. Fill in details about the top features and break down the features into work stacks with details. If the stack starts running low mid-week, put in a kanban for feature breakdown. Stop the line, breakdown features and reiterate. This way there is continual flow.

One thing this does is force small changes. Small changes are critical to agility, they are mutually inclusive. You have to be able to ship and switch gears to be agile - by definition.

On a personal note, I've always found the Sprint (of the Scrum process) awkward due to the fixed time box. Because of that fixed time box, we're forced to jam ill-fitting work into that box. Often we over-scope because we're inherently optimistic - to a fault. It makes more sense to me to make landmarks out of shippable features or feature sets. Estimation comes from measurement of past sizing...instead of asking "how long will this take to develop" we use past data on "how long will something this size/complexity take to deliver", a more important prediction by far. It's also easier to measure - when did we start and when did we release it and actually start to realize its value (lead-time). That's what really matters anyways.

Thursday, April 20, 2017

How to Kanban

Kanban - unless you've been in a prison camp for the past few years, you've at least heard about it. It's origins are in manufacturing - where they have to repeat the same task over and over (major implications). It's been ported to software development. The basics of the entire TPS (Toyota Production System) are about reducing waste and Kanban is one small part of that entire principle - Kaizen (reducing waste/continuous improvement) is one of the other important principles that make the TPS successful. In order to truly port those principles into Software Development, some of those principles need to be applied differently (in a software environment sort of way) in order to optimize throughput and reduce waste (the main goals of the TPS).

The start is the all ways. Start building your process with the end in mind and with the realization that YOUR process will depend on YOUR environment. Perhaps your environment benefits greatly when there is waste or when things take longer to accomplish, IDK. I'm only taking the happy path into consideration here - where your goals are to reduce waste and increase throughput (without reducing quality or increasing costs).

Most commonly, in software, the application of MVP (Minimum Viable Product) is used to reduce waste and that is a good start. Sometimes, and probably not rarely, important parts (artifacts) are cut out of the process in the guise of reducing waste. It's been covered already so I won't go there. I will focus right now on the kanban itself...the card.

A kanban is a card that represents a work order from downstream. Kanban move upstream and results move downstream. The kanban is a visual, tangible representation of something that a downstream step needs in order to do their work to deliver working product. All the way downstream sits the consumer. In software, data flow one way, kanban flow the other way.

The Kanban board is a visual way to see what's going on, but its located centrally somewhere so everyone can see what work is in process. This works when the team is co-located, but can easily fall apart when distributed. Each area should generally have its own board. These boards represent requests for work. Downstream should have a prioritized queue of all the work, those cards should be maintained by whomever is directing or requesting the product (the program manager, "the customer", the product manager, the BA whatever). The thing is, kanban move upstream in a pull system...usually starting at the end of the dataflow...the end-result.

For each work request, you need more than one for the board and one for the person doing the work. The one for the board is so that everyone else knows where something is...when its being worked on, the person/pair/team doing the work is indicated by placing their card on the work card...they get a copy of the work card.

Lets take a quick walkthrough of this process in action -
Lets say were doing a User Management thing. First story is add users - "Add Users Page" kanban goes to UI team. "User Persistence" goes to the backend team just before the UI team really needs persistence. Integration happens, goes out for testing. QA almost immediately sends a card to the UI team "View Users" because they can't see the users they just added. UI team puts a card in to the backend team "Get Users", works on view while waiting for data. UI team gets back the "Get Users" card and integrates. .QA gets the "View Users" card and checks it out. Now someone has the idea to edit users so those cards flow up and the feature flows down. Disable user becomes a thing and so on and so forth - cards flow upstream, features flow downstream.

That's it. That's all Kanban is. It sort of solves some things, but really there's a lot more to the whole TPS system that is of GREAT value to software teams if one has the impetus to use them...continuous improvement, Gemba (go to where the work is)...Gemba is a good one. It's just walking over to someone's desk and seeing what they're doing and how they work - understand their work and challenges they face. Pretty easy right!

Here's a good one - Stop the Line! If something isn't working right, stop the line and get it fixed - crash the problem, meaning everyone get to it and anyone has helpful ideas please let them be known.

Continuous improvement - always look for little gains in efficiency and reducing waste. Maybe its wasteful to have 4 manual steps in some process that could be automated and would reduce process time 80%. If that process is repeated 3x per day that's a lot of waste to reduce.

The moral? Doing Kanban is about an entire cultural alignment around Lean practices. It's pretty easy to do with some basic principles...and some obvious benefits...once you understand the nature of it.

The next daily lesson learned goes deeper into some details about the details.

Tuesday, January 31, 2017

Database Development The Iterative Way

As I recently became more involved in developing a data layer (including database) I've been learning a new style of database migration. Previously, I've written plain SQL for database migrations for each deployment. Those were handed off to a DBA to run in each environment.

These days, I've entered the realm of Liquibase. Liquibase is my first experience with this sort of tool that allows for source controlled, database versioning. It's written in declarative style and translates the declarations into the underlying SQL. It's cross-platform and supports multiple declarative languages (JSON, XML).

Here's how it's changed my development process: In the old days, I used to write the SQL and run each file or put it all in one file and run as a batch. Then write some queries to validate, interrogate the schema etc. I would do mostly up-front design of the database components. Most of the queries and commands were generated by EF or in code. Other factors have changed that as well.

Nowadays, I'm writing a lot more stored procedures with none of the sql in code or generated by code. I'm writing tests first. Then I'm writing stored Procs, then creating/modifying tables declaratively via Liquibase. Sometimes I don't care about the table of the column until it's really needed. Sometimes the name of a column morphs during an iteration (a short cycle of failing test-code-passing test on the order of minutes). Nowadays, no problem! It's relatively simple to change a column name.

The big trick/advantage is that everyone else can pull in those source controlled changes and have their local databases updated by running a batch file or using a git hook. It only applies changes that are new on the target database, so if they haven't updated in awhile it'll apply all those changes until they are up to date.

It's all good! I never really had a chance to dig into EF code-first migrations to this degree. If its the same or similar in efficiency, I would recommend it for sure! Or any tool that enabled rapid changes to the backing store which has acceptable trade-offs (here's looking at you noSQL).

Tuesday, January 26, 2016

QA Perspective

I  gained a new perspective today after attending an event hosted by a QA group. The event was about how to influence change towards BDD (Behavior Driven Development). There was a remarkable turnout with a packed house and some folks sitting in the back without tables. I (as a developer) was in a room with a bunch of QA folks. The topic was BDD, which from my understanding so far was of more interest to developers than QA.

As it turns out...the focus from the QA standpoint was on changing the way development works. I've always viewed BDD as a fundamental change in the BAs worked. I guess it really goes to show that the ones downstream in any hand-off type of work are going to have the most interest in changing the patterns of those directly upstream.

This FURTHER reinforced this same realization I had last week when doing a penny passing experiment while in Agile training. The experiment, which seeks to show efficiency gains in iterative work over waterfall, goes like this -

setup - form groups of four, one person keeps time, the rest pass coins.

first run - pass a batch of coins one at a time from one person to the next. Each passer can't pass coins until he/she has the whole batch. Timer times from start to receiving all coins. This mimics waterfall and the coins represent deliverables.

second run - pass coins one at a time as soon as you have coins to pass. Time when the first coin reaches the end and when all coins reach the end. This is iterative.

In the waterfall process, ever one who is not passing coins is watching the coin passer. Clearly this takes longer and results in waste. In iterative, everyone is working with excitement and fervor to pass those coins along. Each is paying close attention to the upstream passer because that's where the coins are coming from. How about that?

Think of the iterative approach for a bit. If we do this over and over again, and we can talk in between each attempt - then we can make incremental improvements to the process of passing coins and seriously reduce our throughput over time. This is old-hat by now in software. Yet it seems that so many organizations are still struggling to work together to make improvements. Another antiquated notion seems to be the hand-off. Clearly the handoff leads to waste. Imagine the same penny experiment, but where each coin from the pile is passed by the whole team at once.