

Our Development Process: 50 Months of Evolution - tablet
http://www.targetprocess.com/articles/agile50months/

======
lucaminudel
Really interesting report I begin with questions to understand more teams
context and to get to know other aspects that are interesting to me.

1) How often teams released in each of the 4 years

2) What is the state of the code-base (i.e. how many parts of the code devs
would prefer not to work with, how many bugs are discovered only in
production, what is the CC, what is the size of the longest method/class, how
many conditionals and static members are in the code, how much time it take
for a new team member to do it's first check-in)

3) What about collective code ownership ?

4) How many time you discovered/learned things only after releasing a feature
and how are you dealing with that now

5) How much unknowns, uncertainties, unexpected-unpredictable events and
changes there are in your domain and business and how you deal with them

6) What about devops and support and operation of the system in production?

7) what about the features released, how much they are the right features for
the users and for the stakeholders ? how much early the team spot the wrong
feature?

~~~
tablet
Wow, thank you for so many questions :)

1) How often teams released in each of the 4 years

We release new builds every other week. Sometimes more often, sometimes less
often, but on average every other week.

2) What is the state of the code-base (i.e. how many parts of the code devs
would prefer not to work with, how many bugs are discovered only in
production, what is the CC, what is the size of the longest method/class, how
many conditionals and static members are in the code, how much time it take
for a new team member to do it's first check-in)

Code-base is quite good. There are some parts that are complex (like custom
reports), but in general nothing is so bad that anybody hates to touch it. I
can't provide any metrics on method/class/static members so far, will try to
gather them soon. Usually it takes 1-2 days for newcomer to dig into codebase
and start bug fixing.

3) What about collective code ownership ?

There are no owners. Sure, some people are more fluent on some areas, but
everybody can change everything.

4) How many time you discovered/learned things only after releasing a feature
and how are you dealing with that now

There were 2 major fails last year. One caused by missed requirements in
Subversion integration plugin and another one due to critical bug found on
production. That is quite rare cases. Sometimes bugs indeed come from
production, but most of them are minor. Our testing process is good enough now
to catch almost all critical bugs.

5) How much unknowns, uncertainties, unexpected-unpredictable events and
changes there are in your domain and business and how you deal with them

Well, agile domain is quite fluid. But there is no immediate changes. In
general we should react every year on latest trends in agile domain.

6) What about devops and support and operation of the system in production?

We have a dedicated support team (4 people) and 1 developer almost fully
dedicated to support issues. Other developers help customers as well when
required. We provide live chat support, email support and live skype sessions
support when required. Support team is really responsive and to be honest that
is one thing I proud of.

7) what about the features released, how much they are the right features for
the users and for the stakeholders ? how much early the team spot the wrong
feature?

We don't have stakeholders, only end users. Product vision comes from various
sources, mainly from customers requests. However, we do not implement requests
blindly, but try to find root solution. Last year we released only useful
features, all of them are used by customers. Previously there were quite many
mistakes and software started to bloat. We cut some features off and now are
very careful with new functionality.

~~~
lucaminudel
Let see if I understood correctly.

10) Now teams are releasing in production every other week and with single
branching and the continuous delivery teams are going in the direction of
daily releases (as soon as a single feature is ready is released). Do I
understood correctly ?

11) Your domain and requirements are pretty stable so are technology and teams
and people involved (i.e. few unexpected/unpredictable events and changes, few
unknowns and uncertainties) and teams are able to deal with the challenges
well with anticipation and reflections and with less/minor needs for
reaction/adaptation/explorations. Do I understood correctly ?

3 additional questions

12) Are release and eventually rollback operations automated just like a one-
click operations and so are the deploy to the automatic test servers?

13) A dev can look in isolation at 1 or few classes and understand their
behavior and can safely make changes and test them, without the need to follow
a dependency chain of more classes and check internal implementation details
(that cannot be understood by looking at public members, interfaces, types,
parameters and their naming) ? Can teams make architectural changes (i.e.
change the persistence technology, change the presentation technology, change
the authentication method/technology, change the caching or session state
implementation) comfortably and gradually and without pain or huge risks ?

14) When you removed the time-boxing and at the same time adopted some kanban
practices (from the report I understood WIP, leading time, just-in-time
meetings as retrospective and planning) have you considered the possibility to
keep both (as I understood time-box and kanban practices are compatible and so
kanban and meeting with a fixed cadence are compatible, so as I understand all
are valid options that team can adopt) ? What teams sensed in order to make
the decisions and what consequences have observed ?

~~~
tablet
> 10-11)

Yes. However, daily releases are possible for SaaS solution only.

> 12) Are release and eventually rollback operations automated just like a
> one-click operations and so are the deploy to the automatic test servers?

Yes, deployment is automatic. Roll-back is semi-automatic so far, but we are
working on fully automatic roll-back and it will be ready soon (for SaaS).
However, customers can install TargetProcess on their own servers, and in this
case there is no automatic roll-back.

> 13) Can teams make architectural changes (i.e. change the persistence
> technology, change the presentation technology, change the authentication
> method/technology, change the caching or session state implementation)
> comfortably and gradually and without pain or huge risks ?

UI layer - yes. Caches and persistence layer, not so easily. Codebase is 8
years old in some places and definitely there are parts that are hard to
modify. Several years ago speed was more important than code quality, so we
have dome debts to pay. New code is very clean and cool, old parts of the
system refactored gradually.

> 14) When you removed the time-boxing and at the same time adopted some
> kanban practices (from the report I understood WIP, leading time, just-in-
> time meetings as retrospective and planning) have you considered the
> possibility to keep both (as I understood time-box and kanban practices are
> compatible and so kanban and meeting with a fixed cadence are compatible, so
> as I understand all are valid options that team can adopt) ? What teams
> sensed in order to make the decisions and what consequences have observed ?

The main reason to try Kanban was an ability to release each feature or bug
fix separately, so we did not considered cadence of any kind. I don't think
cadence is required in Kanban. But definitely team can keep it and see how it
goes. Changes were not easy initially, but in 2-3 months situation improved
and it was clear that Kanban works better for us.

~~~
lucaminudel
Nice to hear of teams that found sustainable approaches to sw development and
still pushing to improve. Thank you very much! A really interesting report.

------
lyndsayp
This is a great article Michael. I admire such openness and transparency. A
very inspiring and thought provoking read. Many thanks for making this
available.

~~~
tablet
Thank you!

------
tfnicooo
Great read.

I wonder, how does the "Salary depends on learning" work?

~~~
tablet
We have a discussion with every employee each 6 months. This discussion is
open and we chat about topics that were learned, knowledge that was improved,
etc. This affects salary rise (as well as good performance overall).

~~~
lyalius
Thank you for great post!

How are you estimate how much you would rise depending on employee
performance? Do you have metrics or just by intuition?

Also, it's interesting what questions do you discuss in order to understand
that somebody was improved since previous review. How many books have been
read or something else?

------
m-x-m
Where and why you are using Python?

~~~
tablet
Here is the story. Initially Python was used to simplify, automate and speed-
up REST services testing. It appeared, that scripting language is a perfect
fit for DSL we want to create. DSL I'm talking about serves several goals to
end users:

\- Filter anything. Like get all work assigned to у AssignedUser.Contains(Me)

\- Add entities into system quickly

\- Do batch operations on entities. Like movetoproject('45')

\- Define own macros and use them (VERY advanced feature)

def rejectIdea(e):

e.entityState = 'Closed'

e.comments = [comment('Sorry, we are not going to implement this idea in the
future')]

e.save()

Basically, I am speaking about CLI (with autocompletion) for end user. It is
VERY uncommon for web application to have CLI, but I personally think it is a
killer feature to advanced users who wants to be really productive with the
system. Python is used to create and engine for all these operations I've
described above. In future end users will be able to program own behavior.
Sounds a bit crazy, but still it is worth to try :)

