sebsonconferences

The agile weblog of Sebastian Schürmann

Ideas for modern coding

If starting a new web project follow some basic principles

  • Start with deploy code – It must be deployable from moment 0
  • Use Unit- and Functionaltests
  • The deployed code is testable and thereby you can verify it
  • Use Virtual machines to recreate the live environment
  • All is in GIT – dev and ops code
  • Use cont. integration and cont. deployment from moment 0
  • Static analyze the code – it’s cheap
  • Build in monitoring and logging
  • Whatever you do, write some docs, build them automatically

I think I will try this. Using this one would end up with a recreatable environment, that 5 years later, everyone who wants to use the software, can recreate. It’s not ma a magic bullet, but I think it could speed up a lot of things heavily.

A day setup can save you a lot of worries. The less you depend on things made “by hand” and if you put something aside for a while, you will be able to return easily.

 

About a Bridge Thread

Reading the C2 wiki, in the context of extreme programming, a bridge thread is

The first iteration of an XP project should aim to be a BridgeThread : an end-to-end application, which does not have to contain much significant functionality, but from which the rest of the system can be hung. The BridgeThread determines the system architecture. In this XP works much like a weaving spider

Bridge Thread

The bridge thread tries to answer a question that is posed very often and I do hesitate to give an more specific answer than: “Just pick ANY, it will be a long effort to build this product and in X months, what does it matter with what we started”.

The idea of the bridge thread tries to answer the same question. Some ideas (far from complete) regarding the Bridge Thread

  • Make sure it is as independent as you can from other stories. It is the beginning, so one of the primary concerns, even more than in later sprints is: Deliver something.
  • Make it a core functionality for your product. If you write a app that helps you getting a cab in a city: Do not make it the login. Try to be as close to the part that delivers the value to the customer as possible. Most likely login is not your main business case. (I have advised otherwise in the past … I changed my mind)
  • Don’t take any shortcuts. Use a small story, but implement it completely
  • Don’t sweat it . It is sprint 1. Getting shit done is more important than getting a lot of shit one. Not producing any bullshit is even more important
  • You will have to set up a lot of stuff: CI, automated tests etc. Did I vote for a small Story already?
  • All layers included. use a story that needs all layers of your architecture.
  • Your estimates are most likely not really good in the beginning. You could pull a story, implement it and pull the next one. Story by story. This is how a Kanban team could approach such a problem.
  • Don’t commit to a sprint goal .. just try. There is no real way to commit to something you don’t know.
  • Have everything extra-ready. All assets. Maybe a DB design. Architecture? You should have a good Idea of this. As much as I love emergent Architecture and Design, just don’t try always when the last responsible moment for that is. One or two extra hours invested wont hurt. Beforehand the sprint. Not 20 minutes before you start the story.
  • Try to hammer a estimate in SP on the Bridge Thread anyways. And Re-Estimate in later sprints. This way you can make sure, that the learning, that took place in the first sprint lands in later sprints.

Do you have more hints what to choose for starters in bigger “Projects” or at the beginning of a new Product or Codebase? Please share them below.

Blog Posts will be moved.

I will be moving some of the posts from here to a new site that will host dissident trainings and all workshop related stuff.

If someone has ideas on the final jekyll site or a way to move posts from wordpress.com to a new blog (my seo friends): please send me ideas and hints.

The posts that will be moved get a tag: ‘dissent

Dissdent Trainings – Preamble

sebsonconferences:

This was written a while ago. It proved valid as a guiding document in how to organize self-employed work by providing a manifesto instead of “hard rules”. So if you want to know, why I changed my Bio status to “Funder/Trainer” instead of “Looking for a Job” (No that I don’t, but I am not the kind of guy to sit tight and wait – So why not create a well crafted business here):

This might be the first post of a few that try to explain this move, it’s implications and the funny stories alongside.

Btw: The thing has a name: Dissident Trainings and a github account

Originally posted on Dissident Trainings :

Dissidents of (agile) Trainings

This is the preamble of the effort to create a company providing trainings for the field of software development in the 21st century. The base assumptions we are building this company on are outlined in this text and should guide us whenever we have questions about the products that @d_trainigs is delivering.

No is the perfect answer

Agile development started as a countermovement to traditional software methods, at least the business thought so. In fact most elements in the body of methods we call agile development today are either from manufacturing (lean, kanban etc.) or cold war WMD projects (IID – Incremental an Iterative Development, today called Scrum). We should not neglect the fact that, method-wise, these ways of working have proven to be effective and efficient to develop high quality software and products, but when building on the shoulders of the pasts giants to remix…

View original 712 more words

Goals vs. Capabilities

Originally posted on Liz Keogh, lunivore:

Every project worth doing has a vision, and someone who’s championed that vision and fought for the budget. That person is the primary stakeholder. (This person is the real product owner; anyone else is just a proxy with a title.)

In order to achieve the vision, a bunch of other stakeholders have goals which have to be met. For instance:

  • The moderator of the site wants to stop bots spamming the site.
  • The architect wants the system to be maintainable and extensible.
  • The users want to know how to use the system.

These goals are tied in with the stakeholder’s roles. They don’t change from project to project, though they might change from job to job, or when the stakeholder changes roles internally.

Within a project, we deliver the stakeholder’s goals by providing people and the system with different capabilities. The capabilities show us how we will achieve the goals within the…

View original 327 more words

So that the crazy ones don’t forget

Here’s to the crazy ones.
The misfits.
The rebels.
The troublemakers.

The round pegs in the square holes.
The ones who see things differently.
They’re not fond of rules.
And they have no respect for the status quo.
You can quote them, disagree with them, glorify or vilify them.
About the only thing you can’t do is ignore them.
Because they change things.
They push the human race forward.
And while some may see them as the crazy ones,
We see genius.
Because the people who are crazy enough to think
they can change the world,
Are the ones who do.

Effective Meetings

A lot of people find meetings ineffective and boring. They feel forced into something and feel they are wasting their time. On the other hand we are working in teams. So getting together and doing something is just one part of the “Team Game” you are taking part in. It is not avoidable and certain stuff is just more effective in a group or must to be done with a group.

1. Invitation

Every meeting must have an invitation. This invitation consists of a Title and a Description of the meetings goal(s) and contents. All the materials that are contents of the meetings should be added to the invitation in order to keep informal parts brief.

Optional: Add a time Schedule. Everyone will be able to know for themselves if the meeting is going into the right direction.

Example:

Decision on Meeting Rules

Dear team, I have worked on some meeting rules, that I want to install company wide. As you all know, I have interviewed people through out the org what they find acceptable and important in meetings as well as what they dislike. Out of this I distilled a set of X Meeting rules that I want to install as a general rule for everyone in order to make sure we dont waste time in meetings. 

Schedule 

  • Welcome (5 min)
  • Presenting the rules and the reasoning behind them (10 minutes)
  • Feedback on the  rules (10 minutes)
  • Break (5 min)
  • Open Discussion – Mini Fishbowl (15 minutes)
  • Voting (5 minutes)
  • Closing (5 minutes)

You find all the informations that I gathered in the attachment feedback.pdf and the propose rules in rules.pdf.

2. Law of two feet

I got this from Open-Space.

If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else.

There are those meetings where you don’t know if they are effective or you can be effective in them. Just show up and leave if you don’t want to participate anymore. It is a powerful instrument to know that you can leave anytime. That is a bit like having a Safeword.

3. Time box

A meeting has a definitive time box. Make this timebox not exactly 60 minutes. Make it 25 minutes, 55 minutes (with a 5 minutes break after 25 minutes), or 85 Minutes (incl. 2 breaks). There are people, whose job it is to attend a lot of those meetings (Project Managers for example). Having and using up 60 minutes time boxes will make it virtually impossible to have one meeting after another. As soon as they leave your room at 13:00 and have more than 0 meters to move, they will be late. Same goes for resources like meeting rooms: They are used constantly, so the moment you are using you rtimebox of 60 minutes to a full extend, someone else will be late.

If the meeting can be finished early, fine. If it will take longer: Schedule a new one or do whatever it takes. But don’t break the time box

4. Protocol decisions. 

Decisions and important points must be documented. You are already sitting in a meeting with some people, using up a lot of working hours. If the content of the meeting allows: Use a public Wiki or folder in Google Docs (or whatever means you have in your company). The decisions made and feedback gathered is the value that was created with massive cost (8 persons *1 hr = person day)  so please be disciplined and write a protocol. Just one person in the room document stuff. If you are sitting in a room and don’t have stuff to document, you are probably wasting time anyways.
These protocols make a great and probably searchable “brain” and “memory” of your company.
There might be stuff that needs to be accessible for a smaller round of people. But be aware: ANY effort to  keeps stuff “private” or “secret” is a cost to the company.

Mail the link to the protocol to everyone who was invited (!). Especially the “dropouts”, who used the “law of 2 feet” or didn’t accept the invitation at all will need the information.

5. No devices

Apart from a laptop for the protocol and stuff that needs a projector I don’t want to see any mobile phone, google glass or whatever in your hands. Stop checking company Mail, Tinder dates, Facebook status or what ever you are doing. If you can’t give the meeting you undivided attention: Goto 2. You are disturbing the meeting. This accounts especially for bigger get togethers. How often did I observe 50 people in a room and minimum 10 are checking on their phones. Just for an experiment question these people privately about the contents of the meeting. You will find out that it is hard to memorize stuff when you are looking at the latest set of cat pictures.
Best thing is to get people used to the practice of making a staple of devices or put them all in a box.

 

I think this set of rules makes sense and I would love to get some more opinion on what other people use as ruleset for meetings.

The hen and egg problem

Imagine, you do a project with a UX guy. He is building the UI and expects an api while doing so.

The Problem

The API will change and new methods will be required as well as changes to “old” parts of the API. You are creative, right? Not everything is laid out in a User-Story, right? New features lead to new Ideas, right?

This leads to a slow down in the cycle. A Server is a different thing. If you want to release, you need a working server component and the client. In order to build a stable one, a defined interface in terms of a restful API would be a good start.

However, this Ping-Pong has a price: time.

Fake it, until you make it

A good Idea would be a API prototype, kinda easy to create and change. In a very short amount of time. Save the time for the concrete implementation of the API by using a mock System.

Interfake is a tool which allows developers of client-side applications of any platform to easily create dummy HTTP APIs to develop against. Let’s get started with a simple example.

Interfake on Github

Playing Ping-Pong with the UX guy just got faster.

Finding out (learning) the requirements of an API is part of the building process (Hello no estimates folks). The cycle time here, goes down (Hello Kanban Community).

Optional: You could create a bunch of tests for the mock API to code the real API against. This is not implemented (yet?). This would be a nice Artifact for a TDD process, right? Estimating a User-Story in a agile context that already has a bunch of ready made Unit-Tests is easy? I would think so.

 

 

 

 

 

How to reduce scope

So, you have the problem that you can’t meet the deadline? You added people and circulate ideas about cutting on quality in order to meet the deadline? What to do as a product owner in this situation? Your Backlog is big and  full of shiny stories, but you can’t build them all? It’s sounds a little receipish, but bare with me for a moment. Here is a genuine idea: Use a relative weight backlog! What you need:

  • A set of user-stories organized as a relative weight backlog
  • Stakeholders and Management
  • A room and time (up to 3 hrs)
  • Explanation of Value+Benefit, Storypoints and Risk
  • Some techies around to answer stakeholder question
  • A general estimation by the stakeholders, how much value in % they want to give up, in order to meet the deadline. It’s a estimate ;)
  • A empty list of stuff to remove

What are you looking for?

1. Stories that have Zero Benefit and Zero Penalty. 

These should not be in the backlog anyways. If there are no dependencies to other stories, there should be questions about how the feature landed in the backlog in the first place. If you find dependencies, see if you can resolve them. Put all the items on a list.

2. Stories with low penalty or low benefit. 

These can  be discussed. piece by piece. Document every decision when you start closing the stories. You got the stakeholders in a room. They can make it happen. They can remove stuff from the backlog. Add stuff to “the list” while you have the discussion. Check on the dependencies.

3. Stories with high risk. 

Depending on how risk was defined  by the team, choose items with a lot of risk involved. Remove carefully. Risk often is related to security/scalability etc.: discuss carefully, be nice to developers.  On the other hand: There can be gems. Maybe a little value created is covered by a big technical risk.

4. Others

You got your own ideas about what should be in or not? Good: After a team already created a relative weight backlog in the first place every stakeholder and developer should have the right infos already. Add stuff to “the list” The work begins!

  1. Check if all Stories are rightly in the list. If there is to much objection: remove it from the list, back into the backlog.
  2. Sum Up the Value removed. Try to stay below the value that was initially agreed on.
  3. Make a decision about “the list”: “If technically possible remove this stories.

Meeting ends here Now the Product Owner works through the list and makes all this sad calls to People who will not receive their feature. Sad Panda day. The team works through “the list” gives it a shot to kill the stories. There were those dependencies: you might have to write new stories. Be nice and give it an estimate. If you are not estimating … ok … you just have to be sure you are removing more than you add. The “agreement” Meeting  Back to the meeting room with team, management and maybe some stakeholders. The rest of the list is presented. This is what will be removed. The Team and PO present the changes that have to be made and the consequences that arise out of this. This is what will be added to the backlog. Let people ask questions. End the meeting (everybody agreed already to what will be removed) Remarks

  • Don’t mix this up with a discussion about deadlines. It’s about removing scope. Have this discussion with a smaller group. You removed stuff, come up with an idea how much time that saved. So easy then.
  • Yes, you have to have a relative weight backlog. The process of estimating it in the first place speeds up the sessions about removing scope.
  • Doing this is a serious effort. Prepare the sessions, make everyone aware that removing stuff from a already filled backlog requires effort in the first place.
  • I would estimate 3hrs for a 60 item backlog in the first meeting, the effort for the re-planning
  • If you have your qualitiy requirements in the DOD or DOR, there is a lower chance for cutting of quality (win).
  • Everyone took part on the decision, lower chance for bad feedback on the big project retro.

Social Human Architecture for Beginners – The Booklist

While giving the Talk about “all those soft skills”, I referred to a lot of Books and Papers that someone could read. I will list all of them now

Introversion / Extraversion

Maslow

Non-Violent-Communication

Weinberg

Conway’s Law

Tuckman

Daniel Pink

Flow

McGregor

I hope those are of value for everyone who participated in the talk.

Follow

Get every new post delivered to your Inbox.