15 November 2017

Architects in an Agile/Lean World

I just read this very nice post from Martin Fowler on The Role of an Enterprise Architect in a Lean Enterprise. He has a lot of good thoughts in there. 

I submit that there is one aspect lacking emphasis in this post however, the responsibility of the agile team to interact with the architect. That is, agile or not, architecture is still a thing in every organization. At some time, some person made a variety of choices about how systems should be structured, interconnected, and in some cases to be implemented. 

Those decisions were not made lightly or in a vacuum and often the consequences of changing them have far reaching consequences that may not be apparent to those without knowledge of the entire enterprise system. Consider that an architects job among other things is to deliver value to the business over an extended period of time. Part soothsayer, part Oracle, an architect should be working to further enable business objectives through technology, not just in the near term, but for the foreseeable future of the organization. 

Architects, like everyone else, are fallible human beings and they cannot foresee every circumstance. Any given project may run afoul of gaps in a generalized architecture or may struggle to integrate two technologies due to any number of compatibility factors. These are times when an agile/lean team should be reaching out to the architect for help. As Martin points out, part of the architects job is not to say 'No' but to make sure the team is fully aware of the consequences of deviations from the current technology stack. 

Failure to consult with the architect when these decision points are reached is just plain negligence. Furthermore, failure of the architect to respond and cooperate with the team is a gross dereliction of duty. Like everything else in the agile/lean world, the relationship is a partnership with a shared goal and it is incumbent on all parties to participate in that partnership; to cooperate to find solutions.

06 November 2017

Vague

I spent most of my weekend working on my NaNoWriMo book. If you aren't familiar with NaNoWriMo, the idea is to write 50,000+ words in a month, basically a novel. The degree to which you prepare for this event is entirely up to you. I've been talking about what I would write about since July, but I haven't really developed the details. 

So, I'm trying to write about gang members in Mexico, but I don't have a town name, a general description of the town, etc. I haven't even named the gang. Its all pretty vague.

So the problem with that is, nothing in the descriptions is named. Or if it is, it's in general terms. The Pontiac. The Boulevard. The Restaurant. Obviously, those are details I'll need to go back and fill in at some point. 

I've witnessed a parallel in project teams. Teams where an idea is discussed, changing the messaging infrastructure for example. The idea is discussed periodically in non-specific terms over an extended period of time, but there are never any details. 

Two things tend to happen. Often, because there is nothing concrete, the work never happens; it remains a goal that is unachieved. The other is, the work is attempted, but it is a horrid mess of a change because there wasn't agreement about the 'how and the what'. 

Don't get me wrong, I'm all for late binding on the 'how and what', but that ultimately has to happen. There should be a progression of work toward that 'how and what', maybe a series of spikes to prove or disprove things about the intended approach, but those need to be focused a little. Someone, someplace, has to provide a specific objective or set of criteria in order to focus the work.

There are a number of ways to get there. The Architect, as a technical product owner, can specify a set of behaviors required of the system. The Tech Lead could specify an approach, either in how the interaction should work, or even some specifics about the tool. The Director of Engineering might also have requirements about cost, platform selection, etc. Without these hints and nudges a team could drift aimlessly trying to make the change happen. 

One last thing that is essential. The work has to get scheduled. It won't just happen in between other cards on the board. The product management team must make a change important and schedule it; set a goal date for completion, or otherwise do something to cause the work to happen. Even if a development team agrees upon the importance of a change, they are beholden to the planned work. If it isn't on the schedule, it just wont happen.

03 November 2017

Microcosm

I live in a microcosm. 

So last week I went to SCNA and talked to a bunch of people there that I don't talk to enough. I've also been having lots of conversations about How it Should Be Done™

So many of the people I've been working with over the past 10 years or so have very similar back grounds, have read the same books and white papers, and worked in the same environments. There is a significant degree of group-think involved. 

Recently though, I've been exposed to some new people who don't have those characteristics, or rather, come from a different group. I'm learning a lot about how other people think about problems and I'm learning a lot about how other people think. 

I don't agree with some of the things I'm learning; which is to say, I've learned a few new techniques and ways of looking at problems and I don't agree that they are more effective or better than what I was already doing. I'm trying to be careful to avoid a false confirmation on these things of course.

What I find most useful about this experience is that I gives me a change to question how I've gone about solving problems for the last 25+ years. Some days it sucks, because you stand there questioning something you've been doing for 10 years and wondering if you've been 'wrong' for that long. Sometimes it's awesome because you get validation of your technique.

All of us live to some degree in a bubble created by those who surround us. All of us could be fooling ourselves every day in terms of How it Should Be Done  

I highly recommend that you get out, meet some new people (or read some new blogs) and consider that what you think you know as the right thing might be improved upon.

01 November 2017

NaNoWriMo

Today is the first day of National Novel Writing Month. I'm going to be one very busy camper. I hope to be able to get a few posts out each week, but coverage may be spotty. Stick with me though.

Thanks,

.rich

23 October 2017

Functions as First Class Citizens

So I've been doing a lot of thinking and reading on the notion of functions as a first class citizens. In Python, functions are objects, just like instances of classes are objects. So when do you create a class and when do you create a function? 

In my mind its somewhat a matter of style. That is, there is no mandate to use a function in place of a whole class or vise versa. That said, there are certainly times when a class is way too much work and a function will do just fine.

So a function doesn't have state, or at least it shouldn't. That means anything it knows about the world it gets as an explicit or implicit argument. Explicit arguments come in the form of parameters just like you would expect. Clearly implicit arguments should be constants or retrieved values and should never be global variables and the like.

Once you have written your function you can feel free to import it, call it, pass it around. It is pretty handy to not have to instantiate something in order to get some functionality. BUT, is this all necessary?

Again, I think we get back to a style question. I grew up on C/C++/Java with a little Perl thrown in. Discounting structured programming, in my mind everything should be an object and every object should have a class. That is clearly a habit born of Java. 

I would not be critical of an application full of objects. I would not criticize a developer for never having a stand alone function. That kind of style question does not register in my lizard brain as a concern. 

As I continue to play with the idea of functions as objects and functions standing alone I find myself questioning a lot of what I've learned to believe about good design. The biggest issue that occurs to me is, functions just laying about feels disorderly. I have to remind myself that the Python concept of 'module' as a means of organization has some significance. Think module == classy and it feels a tiny bit better.  

Anyway, there is certainly some utility advantage to having free standing functions. For one, no tedious object instantiation. Another benefit in my mind is, you don't have to prefix a function with self. That is one of the least pleasant things in Python in my mind, all this self prefixing (same complaint about OO-Perl etc.). So if typing has somehow become the hinderence to your success, using standalone functions will save you some of that. 

One other thing, in the past we've had this issue of 'where do I put utility functions'. Like convert_to_utc(datetime), a function that given a datetime in some timezone will convert it to the UTC timezone. That doesn't need a utility class, we don't need/want to do Utils().convert_to_utc(datetime) and so the function cleans that up, making it just convert_to_utc(datetime). That is one aspect of the function as a standalone/first-class object that I do appreciate. No more 'common' or 'util' classes cluttering things up.

I have some other thoughts I'll share in future posts but for now, chew on the idea that functions can be first-class citizens in your program.

20 October 2017

Card Numbers

Ever notice that teams who number cards stop talking about cards and start talking about numbers?

Repeatedly I see this happen. A card is placed in a system like JIRA where it is assigned a number. Lets say AB-123. The card has a concise and meaningful title, a complete description, and all the other goodness that a card should have. Prior to being entered into the card tracking system the card was referred to as 'Spell Check Project Name Field'.

Notice, once it is placed in JIRA it is forever after referred to as AB-123. 

The problem that then occurs is that the team stops talking about it as 'Spell Check Project Name Field', it becomes an abstract concept AB-123. As an abstract concept the team stops understanding and communicating it's meaning when they discuss it. As a consequence two things happen; the impact of the story isn't something that can be internalized or reasoned about and a majority of the time the team can't remember what is on AB-123, so when it comes up, nobody really understands what is being discussed.

So here is some advice, stop numbering cards and or don't allow people to talk about cards in terms of the number. Rather, enforce a behavior of discussing cards in terms of what they actually do/mean. 

18 October 2017

Preparation

You've probably heard of the 7Ps, Proper Prior Preparation Prevents Piss Poor Performance. What does that mean in the context of an agile team?

I often use the imperfect analogy of an automobile to describe an agile development team. Simply, the tires are the production system, the drive train is dev-ops, and the engine is the development team. The product owner/architect/tech-lead are the fuel delivery system to that team and stakeholders/business people are the gas-tank. When they all work together the car runs soothly down the track. 

Here's the thing. If the product owner and architect aren't filtering the fuel before feeding it to the team, they aren't doing all of their job. It isn't just about pumping fuel from the tank to the developers, its also about straining out the gunk that might be in the fuel as well as distributing that work somewhat evenly across the team members. That is, making sure the fuel is clean and that every cylinder gets some of it. 

I'm going to just use Product Owner as a proxy for anyone providing requirements directly to the team (Architects, Tech Leads, Engineering Leads, etc. all count as Product Owners in this scenario).

When a product owner shows up with a story, it needs to be fully digested and understood by the product owner. It needs to include answers to questions like For Whom? Why? When? and What? One essential component is of understanding that needs to be present is, what. 

What means, what does this story do or accomplish and in understanding that we need some of the How, but not in a technical sense. That is, we don't need the Product Owner to provide the algorithm or a design document, but rather, How do you do the math? 

An example; Calculate the percentage of ripe fruit on sale for a given date. Sounds simple enough, look in the inventory for all the fruit available for sale who's status is ripe on a given date and the total count of fruit available and do some math. But in real life that might not be a simple query. For example, we may only have available a total amount of fruit, ever. How do we do the math now? Do we deduct the entire historical record of fruit sold from total count of fruit to get fruit available? Then how do we determine ripe fruit? Same way? 

This space of understanding can be solved without the business getting involved. The developers are more than smart enough to figure out a way to get an answer, but it's quite possible it won't be the right one. 

So somewhere in the preparation of the card the Product Owner should have discovered this and documented it. This isn't about stealing the thunder of the brilliant developer and it isn't about providing a how; this is about communicating what is expected. That is, what ratio is the business trying to show.