Archive

Archive for August, 2008

Inviting people onto projects – and giving them an exit strategy

August 29th, 2008 No comments

In my work life, I’ve been running a couple of projects lately where I had choices about who to include on the project team. Historically, I have been unhappy with the approach used by my company. People are essentially an interchangeable resource although each resource should have the right set of skills. Individuals are in fact asked whether or not she/he is interested in the project and willing to join. This all works well enough when there is a match between projects and people. But it assumes that the resource really knows about a project and vice versa that the project knows the skills (and attitudes) of the worker. But what happens when there is a “lack of fit”. Often both of us are stuck with each other. In some cases, you do get to get off the project – often quietly, and in my experience is often undermining. At best you get to get off an ongoing project when you go on extended leave. Thankfully, I go on leave often! Therefore, I want to think about ways which build in inviting people into a project that allows for an exit.

Luckily, I have friends who think about group processes. One friend is a clinical psychologist working with dialectical behaviour therapy (DBT). He’s been having a similar issue. He works in a small group of 6-8 people. It is a stable team but still requires new people at times. The success of that team is each person’s fit into the team and not just their skills – and they tend not to be able know in advance how well the new person will work out. His approach is to give someone 4-6 weeks on the project before reviewing suitability. Within that period it is outlined that the person needs to:
  • read certain materials
  • observe and participate in meetings
  • raise concerns
Central to this approach is to allow both sides to gather knowledge about each other and the environment. They are really looking for the new person to make a commitment to using particular skills and methods. Because, it is the actual using them that is essential. Sound familiar? We need well-functioning, small teams. Here’s what I have been attempting to do over the last couple of projects. This is the basic process I use once we have decided that a person is going to join the team (so this isn’t a recruitment strategy):
  1. Have an initial meeting outlining that I would like to invite them into the team and that I feel it is important that they get a chance to work out whether or not the project is for them.
  2. I outline that once they join that we will have a review at the end of two weeks.
  3. I outline the three points above.
  4. I outline that what we are looking for are people who can contribute to the project (and to me that is contributing to the code as a measure of success)
  5. I outline that these types of projects are not for everyone and that wanting to leave is okay – being stuck is not. I also outline the sorts of struggle that I have had in the past and why I think what we are doing is going to try and work against those problems.
How well does it go? To tell the truth, I haven’t used with enough people to really know. I have noticed that with the people who have been inducted through this process, they tended to contribute well and early. The others that were really given to me and just started have tended to be more of a struggle.

What could I be doing better? I think that I could do the review better. The review isn’t as formal as the initial meeting. It is more of a touching base. I check out with other team members how it is all going. I haven’t had anyone leave yet either – but then again those that I gave the induction approach to tended to well out better!

I’m not surprised that it might work well. It is akin to setting ground rules for small groups. My problem though is that I tend to set the ground rules rather than make them shared and in practice that doesn’t give much of a chance to the new person.

A final point my friend made after I was explaining the agile principles and trying to draw some parallels in our work. He agreed with the agile principles. He could see that a focus on individuals and interactions over processes and tools would be important; or customer collaboration to get working software. But he pointed out that DBT for him helps him think about how to do personal relationships. Now that’s an important point that I don’t think we are addressing in software development models. We might say that people are important and that they interact but we aren’t talking too loudly about its qualities. I’m not reading a lot around what happens when there is difference, such as gender and race, within interactions – is this will become more apparent if outsourcing across national borders increases. At best the discussion is relegated to the level of psychological-based soft-skills – for example, the pragmatic programmers series, such as, retrospectives, project management or management books.

Categories: Uncategorized Tags:

Of course agile is a fad

August 28th, 2008 3 comments

Anyone else getting asked is agile just a fad? Has it gone mainstream? Anyone else wondering why we are seeing people saying, “we’re doing agile” and others arguing that of course they haven’t, it’s just expedient?

According to my loose interpretation of Mary Poppendeick on a Hanselminutes podcast, of course agile is a fad. Well she didn’t actually say agile was, but she did make a comment based on experience. Fads in software development seem to last around 7 years. She argues that this is not surprising because management and management cycles tend to be of that duration. This point suits me. If agile was formerly named around 2000 marking its birth then we may have hit the end of a cycle. Has it hit maturity? Are parts of it being integrated into mainstream? Has the agile alliance achieved it stated aim for agile to gain widespread adoption?

From the look of the papers at Agile2008, perhaps it has reached a certain type of maturity.  There weren’t a lot of new ideas/practices on showcase. Although KanBan and micro releases were one area that was generating discussion. Also UX appears to thinking about how it affects SDLC. There was a lot of adopting/teaching sessions – not surprising the increase in size of the conference to around 1600. So in short, the weighting was against breaking acts and toward leadership.

Let me then pose that in fact the statement/question Is agile a fad? indicates instead that it has already hit mainstream. In answering this question, I wonder how is asking the question in the first place. Is it not  mainstream that can ask that question in the first place? Fad indicates some sense of derision that those in agile wouldn’t tend to suggest. And if mainstream does ask that question, in what ways might we see that parts of (or in full) agile has been already adopted or co-opted? For example, how would you explain that at an agile conference Microsoft has a stand (promoting TFS) that showcases a white paper by Kent Beck for Microsoft on Tools for Agility [don't tell me you can't see the contradictions there].

Of course, the agile-as-a-fad question at its most naive is dismissive. I have been asked it often, we read in the blogs and hear in the podcasts. In my weak moments, it frustrates me, it silences me, it angers me. I get over it. When I am patient, calm or not under pressure, I like think about that question in terms of “discourse”. Let me take some time to explain. I use some very nice historical research from Alice Echols around the role of radical feminism to change overall societal attitudes. Or put in discourse terms, how discourses change over time.

Echols argued that radical feminists changed how mainstream thought about women, and how (liberal) feminists thought about gender relations. These feminists, she argues, were only a very small group, in a small place, over a small duration and left a long-lasting legacy. I’m already starting to make the link between agile practitioners in the last while ;-) Small group, big effect and all that.

Echols argues that radical feminists “dared to be bad”. They did things that mainstream thought were bad. The group was only small. Of perhaps around 4000 women. Primarily in the US and on the West coast, they were daring to be bad throughout the period of 1968 to 1974. Of what we now refer to as radical feminists, it is this group that strikingly were. Of course, there still are feminists taking a radical position and this group didn’t just wake up one morning and it didn’t exist. But she does show that the action taken was finite with a definite effect.

One of those effects was that the form of radical feminism needed between 68 and 74 was no longer needed or appropriate after that period. Many of the tenets of that radicalism which were previously bad, were no longer seen as bad. In fact, she points out that many of these practices can now be seen in liberal feminism – which by definition no longer makes them bad.

Out of Echols’ analysis we see that radical practices are bad insofar as historical moments. Moreover, we need radical practices to shift what constitutes bad from one period to another. However, these types of changes are ruptures in thinking – swings from one thought to another.  That is social thinking (as opposed to people) doesn’t shift from one though to another. We don’t see liberal thinking become radical. Rather it incorporates radical thinking as the shifts are incremental. In this sense, liberal and radical thinking are relative to each other and rely on each other. Radical is necessarily a challenge to liberal thinking rather than an idea separate from it. Liberal in that always holds its ground in relation to radical thinking (and probably doesn’t want to acknowledge it). In this relative position, there is always a struggle going on and who wins and to what extent is not guaranteed. It is less of a zero-sum game that one wins over the other because each position is never fixed for long.

What does this mean for agile and software development? Agile as a fad indicates to me that the agile-as-radical thinking is being adopted and co-opted by mainstream-as-liberal thinking. The few thousands agilists over the last decade have paved the way for making important tenets of agile into everyday common sense. Mainstream software just isn’t the same even in the minds of those I saw say three years arguing they had it right. They (as individuals and corporations) have been injected/infected with new (agile) practices; they have resisted and struggled; they had their own thoughts and approaches.

So when I hear questions about agile as a fad I should just smile and realise that all the work done by the software radicals have made my work life a better place.

p.s. none of this foregrounds that change made should not be taken for granted that it won’t be rolled back. We might see a backlash in the near future that is regressive to software development.

Categories: Uncategorized Tags:

Risky practices:

August 28th, 2008 No comments
I was having some correspondence today with someone I met at Agile2008. At conference we were talking about the role of (TDD) tools to enhancement communication and the nature of relationships. He wrote:
I feel an urge to look less at automated acceptance testing (AAT) and more how the communication between customer and developer team functions. And then how AAT relates to this. AAT has gained some attention, and has been praised as a tool to enhance communication between customer and developers. As were Use Case diagrams back in the last century. And we all know that worked well … What is it with AAT that makes it (supposedly) a good tool for development? What kind of requirements cannot be described in this manner? It is about the learning of the proper requirements, it is about learning that the code can be trusted (as you say), and perhaps also about increasing the trust within the team that they will make the right decisions.
I have quoted this because from this email extract, it started to get me thinking about pulling together some themes I am working on. There is one comment in there that I find both telling and a risky practice: “It is about the learning of the proper requirements”. There are so many assumptions going on the words “learning”, “proper” and “requirements”. For example, in agile would we askew the word requirement in favour of story/scenario, and why? If there is the notion of the proper, what is it? Can proper be determined before the start of the a project or outside of the people on it? If so how is proper related the agile manifesto’s goal of  individual and interactions over processes and tools?

More telling, is a shift into trust – or as some might say, a discourse of trust. Throughout the language seems to be the new benchmark of success – trust of the code, trust between people. Is this the new silver bullet? We know that requirements – a discourse of requirements – has failed us.  We should be careful to assume that trust is any more of silver bullet than requirements. Perhaps, it is no more or less than the current trend to label practice. If that is the case, what are the assumptions and practices which underlie it? Rephrased, then. Perhaps we should trust that we will never get proper requirements; or trust that are requirements are never proper.

Learning is for me is the most interesting word out of the three. I am writing a piece at the moment that is setting the stage to focus on learning. I think that we need to establish in our SDLCs where and why learning is important. Most models still cannot incorporate where the individual and interactions fit in. I have a circular model of development. That model links simple activities with lots of lines. It is those lines which make up the individuals and interactions of the manifesto. I have compared ithe circular model with a model of small batches in a recent white paper by Kent Beck written for Microsoft on Tools for Agility.

What do we mean by learning here? It seems that the current trend is a focus on cognitive psychology forms of education. For example, Drefus’ skills acquisition model (talked about by agile coaches in sessions and also Andy Hunt’s latest book yet to be published from Pragmatic Programmers). There is much more to learning theories that these approaches: radical, feminist, poststructural, postcolonial, kaupapa maori theories of education/learning. But before we can do this we need models of software development that actually provide space for learning inside them. The current trend on process (and tools) occludes and assumes the learning. Given then we have a focused model on interactions, what is it that goes on in these interactions. For me that where I want to think about the metaphor of software-as-pedgagogy. I haven’t written this paper but have sketched out some ideas. It is based on a model by an educationalist in NZ. That is the next month or so of work.

Categories: Uncategorized Tags:

Circular model of development

August 20th, 2008 No comments

The first thing that I want to establish is that I trying to think about software development within a context of something we might want to call agile. So, if agile is a decrease in cycle times, delivering functionality more frequently against bigger batches of work less often, then you can count me in as “doing” agile. I am interested in the types of activities that occur in those cycles. For example, the activities that occur as a result of acceptance testing, unit testing, incremental design, continuous integration.

The other aspect of what we might call agile is to shift the metaphor for software development around people. It is against the idea that software is developed through machine-like processes – repeatable, consistent, predictable. People instead can make decisions, negotiate and be creative in the face of routine and repeating circumstances. So, I am interested also in the types and effects of interactions that happen between people, but that is harder to understand and requires quite a different method of study than reading blogs, books and explication.

Kent Beck, in a white paper for Microsoft on Tools for Agility, argues that the consequences of smaller and more frequent is at least two fold. One, a decrease in cycle times means an increase in the number of transitions between activities. Two, these transitions change the requirements for effective development tools. While he is trying to predict tools needed for the future, I interested in how the current set of tools has already affected the software development cycles. These sorts of tools are xUnit family of test runners that have spawned tdd, bdd, stdd, att; Build server tools and scripting languages/tools that have spawned better build, configuration and deployment management.

It worthwhile going back to Beck’s paper to see his base models. He compares a model of large batch flows with a linear approach to the end point against the smaller batches with transitions galore.

Large batch development cycles

Figure 1: Large batch development cycles

Figure2: Small batch development cycles

In contrast, what I see happening within development cycles is a slight variation on Beck’s small batch development cycles. The small batch model avoids transitions between activities as clean, well boxed straight-lined demarcations progressing forward in a step-wise, linear fashion. Rather, activities transition is predictably messy moving around through known analysis, design and testing activities – but their order and number of iteration up-for-grabs.

But Beck’s model still separates coding from the other activities too much.  I want it to be central to all those “transitions galore”: code for me is both an input and output, a starting point for decision making and a deliverable of that decision making. For me, central to this cycle is code because it is working software that I want most of all.

Circular model of development

Figure 3: Circular cycles

What do I gain from this schematic over Beck’s when his also has a notion of circularity in analysis, design, test? It is a shift in emphasis.  The model emphasises circularity and the repetitious nature of transitions. There is not just the words transitions galore, but the two lines to and from each activity represent the potentially large number of movements around them in any one cycle. At the same, movement through to release is predictable. You have to have passed through all activities in the cycle. You also have a start and an end and implicitly every end is a starting point. This shift of emphasis also suggests that we need to be as attentive to the lines as the activities. It is not just that we need analyse, model and test. We need to attending to which activity to move next to. What have we done? What do we know? Do we know enough? What is the test data? What are the scenarios? How do we add value? Are we done? These are complex heuristics. Luckily software development teams have smart people.

The emphasis on code also takes for granted that we are producing working software and that analysis, modelling and testing are inextricably intertwined with coding. Whatever we do, we add value through code. And making is about thinking and talking, understanding and misunderstanding, acting and waiting. Using these cycles, creating software is a process of developing knowledge and, as you learn more, keeping on going back, rethinking your original propositions and thoughts and refactoring the code to meets its objective.  It is a creative process, somewhat like a feedback loop, and as such is unlikely to be linear.

A transition: focus on cycles over process

You might have noticed that I shift my language around from process to cycle almost interchangeably. Not quite. I use process alongside creating software and being creative. A quick look at dictionary.com comes up process as a systematic series of action directed to some end or a continuous action, operation, or series of change taking place in definite manner. Software then is a process: overall it is repeatable, systematic and has an output. This I would refer to more broadly as the software development process. I use cycle to mark the activities we use inside that process. Back at dictionary.com, cycle relates to any complete round or series of occurrences that repeats or is repeated. It also relates to regular rhythms over time (most notably seasons). To generate software we need cycles of activities. In this model, these cycles all support generating code. It is now time to look at what I mean by code.

What constitutes code?

Code for me is something that can checked into the source code repository and it usually should be plain text in origin. I want it in plain text because it is my real friend. I can track changes, do transformations. It tends not to be proprietary. Five examples of code:
  • objects/classes (eg .java, .rb, .cs)
  • executable specifications/acceptance criteria (eg FIT, StoryTests)
  • test data (eg
  • scripting (eg builds – CC.Net; TeamCity, deployment, reporting)
  • user documentation (eg html and binary formats like swf, docbook, doxygen, dot)
Five examples that aren’t code (but could be):
  • Word documents
  • Visio documents
  • Project plans
These documents don’t tend to be code for me – we use them for thinking but they so often have a large maintenance cost that I use them as in input to a cycle (start). There are times when they could be but I find they tend to be using the advanced facilities (eg Word as an XML document, Visio using the underlying object model).

Code then is central and all the activities of the cycle support this activity: analysis, modelling, testing, documenting. This is away from roles that do these activities. Everyone does these activities, all the time, to generate code. There are two major shifts that occur: First, not just the analysts do the analysing, the testers the testing, the technical writers the documenting or even the programmers doing all the coding. That is not say there are not primary responsibilities and that anyone can do anything – that’s just too nihilistic for me. I find in practice, there are generalists, ideally generalising specialists, and there are people who are good at some aspects of development and not others. It makes sense to me to work with what people want to be doing and are good at.

Second, more than just code as classes-and-objects (and more recently unit tests) are first class citizens of the software process. Specifications, tests and documentation all get a promotion. Promoting these artefacts to code means that people on those roles need real support to move through cycles. I like this because there is a current trend to support developers-as-programmers in their endeavours to create code either by making them as self-sufficient islands of work in the dev/analyst, I-can-do-everything role or making everyone sit around talking about the code. I’ve tried both and met resistance time and time again. So, rather than only focussing on the developer code, the forms of code require developers to support other people (the analysts, testers, technical writers). This is important because these roles aren’t going away, some people are good at specialising, sometimes it just plain makes sense.

Who contributes to the code? Can everyone?

I think that they can. Otherwise, I wonder if I really want them on a project. Put another way, they aren’t central to cycles which, and hence the people who, develop the software. They are part of the process (SDLC) not the cycles.

How does this model relate to different software approaches {methodologies}?

Approaches that don’t work iterative and incrementally I think would make this a difficult way to work. The roles are segregated and people are rewarded for reliably delivering irrelevant outcomes – their documents. [maybe a bit harsh] Just a note on some {methodologies} not covered that Fowler lists as agile in his new methodology bliki: Context-driven testing, Crystal, RUP. Fowler says,
One of the biggest issues with … any agile method, is how to do the essential local adaptation where you alter the process to fit the local conditions.

XP

XP at the face of it is the easiest to relate to these cycles. At the heart of its principles, lies the centrality of cycles, code and communication. Pair programming is perhaps the most obvious practice to connect with. Programmers work in small, test-driven cycles talking to each all the way through. They rotate pairs spreading knowledge around the team. Because I have widen our net of the notion of code, who pairs also is extended. Analysts, testers, build-engineers now need to pair – and that is probably with our programmer, but not exclusively.

Cycles are encapsulated in:  Small releases to put a simple system into production early, and update it frequently on a very short cycle. With continuous integration teams integrate and build the software system multiple times per day. This keeps all the programmers on the same page, and enables very rapid progress, increased frequency tends to eliminate integration problems.

Code can be seen in collective ownership allowing for everyone to contribute to the code base. Here, I am alluding to a greater set of people understanding the anatomy of the code base and knowing which parts they really know they can contribute. The anatomy of the code base ranges from understand file types, their function (eg build, class, unit test, fixtures, configuration files) and organisation within folders through checkin processes, branching/tagging nomenclature. If everyone is required to own this discussions and changes tend to move through with less friction and environment-specific processes tend to be weeded out as they appear. This is supported by coding standard. For a team to work effectively in pairs, and to share ownership of all the code, everyone needs to contribute to the code in the same way, with rules that make sure the code communicates clearly.

Finally, communication. Testing focuses on validation of the software at all times – though unit and acceptance testing that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided. So the on-site customer determines requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy, up-front documentation – often one of the most expensive parts of a software project.

Scrum

Let’s take done as a simple concept that Ken Schwaber was talking about in a interview lately. Done is something that’s potentially shippable. It is necessary so a team knows how many items to select and so it knows what development process goes through within a sprint to create something and so that there is no undone work left at the end of the project for the team to stabilise. But it raises the question, does the team know and agree on what counts as done. If it is only coding and testing, it is unlikely to really be done. Acceptance testing, documentation, scripting still may be still undone. So the “shippable it” is not yet in fact shippable.

I am interested in closing the gap between the done and  undone through making visible the different type of codes that are deliverables for the shippable it. If the team can agree/work out/work through what the code deliverables are my experience is that there is greater likelihood of having realistic list of deliverables that make a shippable it. If this is the case then we might find greater cooperation to get the code deliverables to an agree state/quality.

For example, if the shippable requires not only API documentation but also installation instructions, release notes, technical documentation and user documentation then I am still at a lose at how a team who creates silos for these roles could possible deliver within a 2-4 week sprint in a calm fashion. The user documentation alone is likely to lag development – I know I been there. So we need to think more strategically about how we combine activities to generate our shippable it.

This comes back to code-focussed solutions. Let me pose the best example I’ve seen in bits and pieces. Imagine the product must have user documentation for our web application. We have worked out that screencasts work just fine. Why couldn’t we enlist a team effort that (a) has acceptance tests (b) part of these tests run, says, selenium © using the test data/scenarios (d) and these tests are recorded/captured (e) and checked in as part of the solution (f) additional explanatory information is entered as people do exploratory testing (g) that is added to the tutorial page that is the container to the screen cast. To make this happen requires a team-effort on contributing to the code base. After a couple of runs at this it is likely that you generate all the major touch points in the code base to make this work – otherwise, the build server is likely to fall over, or the viewing version won’t work!

Lean Agile Kanban

{notes} Here I am going to focus on how to make value flow.
  • tasks are broken down from stories and are seen as unit of work to flow
  • everyone needs to agree on what is flowing – what those units of work that add value really are
  • with the flow established, then we can also apply Lean thinking to the whole process
  1. Specify value
  2. Identify value stream and eliminate waste
  3. Make value flow by pull
  4. Involve and empower employees
  5. Continuously improve
The challenge is balancing continuous flow with limiting WIP through a pull system
  • ideal system tell you about what to do next. No more, no less. Anymore is waste
  • allow specialisation at steps
  • stop regulating people and start regulating work
  • puts limits on multitasking
  • KanBan: {Everything is about the throughput of code – but this is problem if the code isn’t the bottleneck}
http://leansoftwareengineering.com/ksse/feature-brigade/

http://leansoftwareengineering.com/2008/08/25/two-axioms-of-lean-software-development/

Categories: Uncategorized Tags:

Circular model of development

August 20th, 2008 No comments

The first thing that I want to establish is that I trying to think about software development within a context of something we might want to call agile. So, if agile is a decrease in cycle times, delivering functionality more frequently against bigger batches of work less often, then you can count me in as “doing” agile. I am interested in the types of activities that occur in those cycles. For example, the activities that occur as a result of acceptance testing, unit testing, incremental design, continuous integration.

The other aspect of what we might call agile is to shift the metaphor for software development around people. It is against the idea that software is developed through machine-like processes – repeatable, consistent, predictable. People instead can make decisions, negotiate and be creative in the face of routine and repeating circumstances. So, I am interested also in the types and effects of interactions that happen between people, but that is harder to understand and requires quite a different method of study than reading blogs, books and explication.

Kent Beck, in a white paper for Microsoft on Tools for Agility, argues that the consequences of smaller and more frequent is at least two fold. One, a decrease in cycle times means an increase in the number of transitions between activities. Two, these transitions change the requirements for effective development tools. While he is trying to predict tools needed for the future, I interested in how the current set of tools has already affected the software development cycles. These sorts of tools are xUnit family of test runners that have spawned tdd, bdd, stdd, att; Build server tools and scripting languages/tools that have spawned better build, configuration and deployment management.

It worthwhile going back to Beck’s paper to see his base models. He compares a model of large batch flows with a linear approach to the end point against the smaller batches with transitions galore.

Large batch development cycles

Figure 1: Large batch development cycles

Figure2: Small batch development cycles

In contrast, what I see happening within development cycles is a slight variation on Beck’s small batch development cycles. The small batch model avoids transitions between activities as clean, well boxed straight-lined demarcations progressing forward in a step-wise, linear fashion. Rather, activities transition is predictably messy moving around through known analysis, design and testing activities – but their order and number of iteration up-for-grabs.

But Beck’s model still separates coding from the other activities too much.  I want it to be central to all those “transitions galore”: code for me is both an input and output, a starting point for decision making and a deliverable of that decision making. For me, central to this cycle is code because it is working software that I want most of all.

Circular model of development

Figure 3: Circular cycles

What do I gain from this schematic over Beck’s when his also has a notion of circularity in analysis, design, test? It is a shift in emphasis.  The model emphasises circularity and the repetitious nature of transitions. There is not just the words transitions galore, but the two lines to and from each activity represent the potentially large number of movements around them in any one cycle. At the same, movement through to release is predictable. You have to have passed through all activities in the cycle. You also have a start and an end and implicitly every end is a starting point. This shift of emphasis also suggests that we need to be as attentive to the lines as the activities. It is not just that we need analyse, model and test. We need to attending to which activity to move next to. What have we done? What do we know? Do we know enough? What is the test data? What are the scenarios? How do we add value? Are we done? These are complex heuristics. Luckily software development teams have smart people.

The emphasis on code also takes for granted that we are producing working software and that analysis, modelling and testing are inextricably intertwined with coding. Whatever we do, we add value through code. And making is about thinking and talking, understanding and misunderstanding, acting and waiting. Using these cycles, creating software is a process of developing knowledge and, as you learn more, keeping on going back, rethinking your original propositions and thoughts and refactoring the code to meets its objective.  It is a creative process, somewhat like a feedback loop, and as such is unlikely to be linear.

A transition: focus on cycles over process

You might have noticed that I shift my language around from process to cycle almost interchangeably. Not quite. I use process alongside creating software and being creative. A quick look at dictionary.com comes up process as a systematic series of action directed to some end or a continuous action, operation, or series of change taking place in definite manner. Software then is a process: overall it is repeatable, systematic and has an output. This I would refer to more broadly as the software development process. I use cycle to mark the activities we use inside that process. Back at dictionary.com, cycle relates to any complete round or series of occurrences that repeats or is repeated. It also relates to regular rhythms over time (most notably seasons). To generate software we need cycles of activities. In this model, these cycles all support generating code. It is now time to look at what I mean by code.

What constitutes code?

Code for me is something that can checked into the source code repository and it usually should be plain text in origin. I want it in plain text because it is my real friend. I can track changes, do transformations. It tends not to be proprietary. Five examples of code:
  • objects/classes (eg .java, .rb, .cs)
  • executable specifications/acceptance criteria (eg FIT, StoryTests)
  • test data (eg
  • scripting (eg builds – CC.Net; TeamCity, deployment, reporting)
  • user documentation (eg html and binary formats like swf, docbook, doxygen, dot)
Five examples that aren’t code (but could be):
  • Word documents
  • Visio documents
  • Project plans
These documents don’t tend to be code for me – we use them for thinking but they so often have a large maintenance cost that I use them as in input to a cycle (start). There are times when they could be but I find they tend to be using the advanced facilities (eg Word as an XML document, Visio using the underlying object model).

Code then is central and all the activities of the cycle support this activity: analysis, modelling, testing, documenting. This is away from roles that do these activities. Everyone does these activities, all the time, to generate code. There are two major shifts that occur: First, not just the analysts do the analysing, the testers the testing, the technical writers the documenting or even the programmers doing all the coding. That is not say there are not primary responsibilities and that anyone can do anything – that’s just too nihilistic for me. I find in practice, there are generalists, ideally generalising specialists, and there are people who are good at some aspects of development and not others. It makes sense to me to work with what people want to be doing and are good at.

Second, more than just code as classes-and-objects (and more recently unit tests) are first class citizens of the software process. Specifications, tests and documentation all get a promotion. Promoting these artefacts to code means that people on those roles need real support to move through cycles. I like this because there is a current trend to support developers-as-programmers in their endeavours to create code either by making them as self-sufficient islands of work in the dev/analyst, I-can-do-everything role or making everyone sit around talking about the code. I’ve tried both and met resistance time and time again. So, rather than only focussing on the developer code, the forms of code require developers to support other people (the analysts, testers, technical writers). This is important because these roles aren’t going away, some people are good at specialising, sometimes it just plain makes sense.

Who contributes to the code? Can everyone?

I think that they can. Otherwise, I wonder if I really want them on a project. Put another way, they aren’t central to cycles which, and hence the people who, develop the software. They are part of the process (SDLC) not the cycles.

How does this model relate to different software approaches {methodologies}?

Approaches that don’t work iterative and incrementally I think would make this a difficult way to work. The roles are segregated and people are rewarded for reliably delivering irrelevant outcomes – their documents. [maybe a bit harsh] Just a note on some {methodologies} not covered that Fowler lists as agile in his new methodology bliki: Context-driven testing, Crystal, RUP. Fowler says,
One of the biggest issues with … any agile method, is how to do the essential local adaptation where you alter the process to fit the local conditions.

XP

XP at the face of it is the easiest to relate to these cycles. At the heart of its principles, lies the centrality of cycles, code and communication. Pair programming is perhaps the most obvious practice to connect with. Programmers work in small, test-driven cycles talking to each all the way through. They rotate pairs spreading knowledge around the team. Because I have widen our net of the notion of code, who pairs also is extended. Analysts, testers, build-engineers now need to pair – and that is probably with our programmer, but not exclusively.

Cycles are encapsulated in:  Small releases to put a simple system into production early, and update it frequently on a very short cycle. With continuous integration teams integrate and build the software system multiple times per day. This keeps all the programmers on the same page, and enables very rapid progress, increased frequency tends to eliminate integration problems.

Code can be seen in collective ownership allowing for everyone to contribute to the code base. Here, I am alluding to a greater set of people understanding the anatomy of the code base and knowing which parts they really know they can contribute. The anatomy of the code base ranges from understand file types, their function (eg build, class, unit test, fixtures, configuration files) and organisation within folders through checkin processes, branching/tagging nomenclature. If everyone is required to own this discussions and changes tend to move through with less friction and environment-specific processes tend to be weeded out as they appear. This is supported by coding standard. For a team to work effectively in pairs, and to share ownership of all the code, everyone needs to contribute to the code in the same way, with rules that make sure the code communicates clearly.

Finally, communication. Testing focuses on validation of the software at all times – though unit and acceptance testing that fulfills the requirements reflected in the tests. Customers provide acceptance tests that enable them to be certain that the features they need are provided. So the on-site customer determines requirements, set priorities, and answer questions as the programmers have them. The effect of being there is that communication improves, with less hard-copy, up-front documentation – often one of the most expensive parts of a software project.

Scrum

Let’s take done as a simple concept that Ken Schwaber was talking about in a interview lately. Done is something that’s potentially shippable. It is necessary so a team knows how many items to select and so it knows what development process goes through within a sprint to create something and so that there is no undone work left at the end of the project for the team to stabilise. But it raises the question, does the team know and agree on what counts as done. If it is only coding and testing, it is unlikely to really be done. Acceptance testing, documentation, scripting still may be still undone. So the “shippable it” is not yet in fact shippable.

I am interested in closing the gap between the done and  undone through making visible the different type of codes that are deliverables for the shippable it. If the team can agree/work out/work through what the code deliverables are my experience is that there is greater likelihood of having realistic list of deliverables that make a shippable it. If this is the case then we might find greater cooperation to get the code deliverables to an agree state/quality.

For example, if the shippable requires not only API documentation but also installation instructions, release notes, technical documentation and user documentation then I am still at a lose at how a team who creates silos for these roles could possible deliver within a 2-4 week sprint in a calm fashion. The user documentation alone is likely to lag development – I know I been there. So we need to think more strategically about how we combine activities to generate our shippable it.

This comes back to code-focussed solutions. Let me pose the best example I’ve seen in bits and pieces. Imagine the product must have user documentation for our web application. We have worked out that screencasts work just fine. Why couldn’t we enlist a team effort that (a) has acceptance tests (b) part of these tests run, says, selenium © using the test data/scenarios (d) and these tests are recorded/captured (e) and checked in as part of the solution (f) additional explanatory information is entered as people do exploratory testing (g) that is added to the tutorial page that is the container to the screen cast. To make this happen requires a team-effort on contributing to the code base. After a couple of runs at this it is likely that you generate all the major touch points in the code base to make this work – otherwise, the build server is likely to fall over, or the viewing version won’t work!

Lean Agile Kanban

{notes} Here I am going to focus on how to make value flow.
  • tasks are broken down from stories and are seen as unit of work to flow
  • everyone needs to agree on what is flowing – what those units of work that add value really are
  • with the flow established, then we can also apply Lean thinking to the whole process
  1. Specify value
  2. Identify value stream and eliminate waste
  3. Make value flow by pull
  4. Involve and empower employees
  5. Continuously improve
The challenge is balancing continuous flow with limiting WIP through a pull system
  • ideal system tell you about what to do next. No more, no less. Anymore is waste
  • allow specialisation at steps
  • stop regulating people and start regulating work
  • puts limits on multitasking
  • KanBan: {Everything is about the throughput of code – but this is problem if the code isn’t the bottleneck}
http://leansoftwareengineering.com/ksse/feature-brigade/

http://leansoftwareengineering.com/2008/08/25/two-axioms-of-lean-software-development/

Categories: Uncategorized Tags: