Feature team is not new anymore; have been around in huge products such as within Microsoft (compiler development) and Ericsson (telecom systems) and always emerged together along with the daily builds. It only became popular upon the advent and introduction of the agile development, as the team focus more on the end-customer requirements as well as shorter cycle times.

What is Feature Team?

A feature team is best defined as cross-component, cross-functional, and long-lived team that completes numerous end-to-end customer features individually. They have the essential knowledge as well as skills to complete the end-to-end features that are customer centric and play an essential role in scaling up an agile development. They generally stay and work together throughout the years and implement numerous features. Without this type of team structure, an organization is more likely to make countless sub-optimizations as well as waste that can lead to sequential development cycle.

Why and when doing it

There are countless reasons for adopting the feature team, but organizations should be cautious of the drawbacks that can be encountered along the way.

Advantages / Disadvantages

The advantage that the feature team brings is that it exploits the speed benefits from a specialization provided that requirements map to the expertise or skills of the team. In case the requirements failed to map to the team skill, learning will be ‘forced’ to acquire or learn the needed skill and knowledge. At large, feature team balance flexibility and specialization.

The drawback is, the efficiency of the entire team will be compromised if one of the members failed to understand the whole system. Not the individual members but the team itself as a whole should to learn the skills to effectively implement the whole customer-centric features. The skills include functional skills such as interaction design, test or programming, and the component knowledge.

Component vs. Feature Team

Feature team differs from component team in various ways. Primarily, the feature team is optimized for providing full customer value and is more focused on system productivity and high-value features while its counterpart is optimized for providing the complete number of code’s lines and is more focused on increasing individual productivity through implementing the lower-value ‘easy’ features. Other differences include the following:

Feature Team:

• Responsible for the whole customer-centric feature
• Increases flexibility through minimizing dependencies between the teams
• Avoids the Conway’s law
• Focus on numerous different specializations
• Responsibilities are shared within the team
• Exploits flexibility; broad and constant learning
• Requires adept engineering practices
• Provides motivation in order to make code maintenance and testing easier

Component Team:

• Responsible for a part of the customer centric feature
• Requires additional planning due to dependencies between the teams
• adhere to the Conway’s law
• focus on a single specialization
• designate responsibility to each member of the team
• exploits the existing expertise; less likely to work on learning new and additional skills
• uses slack engineering practices
• does not believes that motivation leads to an easier way of maintaining and testing code

Which is better between the two? Well, the answer depends on the perspective. If seen from the organizational-flexibility and value-delivered perspective, a feature team is ideal. However, flexibility and value are not the only criterion for the organizational design. Considering this, majority of organizations then tend to end up embracing a hybrid models. Yet, organizations should be cautious with this, as it brings drawbacks that can cause headaches and pain.

— Slimane Zouggari

Comprehending the definition and nature of cost of delay is of paramount importance when developing improved or new products. Learn the basics of cost of delay through reading further:

The Cost of Delay – What is it?

The Cost of Delay (CoD) refers to a means of communicating the effects of time on the anticipated results. It combines value and urgency, which most people find it difficult to distinguish between.  Oftentimes, people tend to focus more on value while overlooking the importance of urgency but in reality, these two things should be given the same importance. The value that can be missed out when something is delivered “late” can be massive.

In simple terms, the Cost of Delay helps people understand and know how time affects the value of something.

Value & Urgency

Having a clear understanding of what cost of delay means generally helps and likely ensures that an organization makes a better decision. It is important that an organization will not only understand and determine the value of something they are working on but also learn how its acquired value diminishes over time.

In general, CoD helps organizations, specifically when developing improved or new products as well as services in three primary ways:

• Decision-making – this was already mentioned above. Whether it is all about controlling the queues length, experimenting with the WIP limits, optimizing the batch sizes in several different points, the Cost of Delay is a piece of information that will be of paramount importance.
• Altering the focus – change the focus from cost and efficiency to value and speed so whatever the organization wants can be likely achieved and those unwanted things will be less likely to be encountered.
• Prioritization – through using the CD3 or the CoD Divided by the Duration, organizations can deliver total value (CD3 is also referred as weighting the WSJF (Weighted-Shortest-Job-First) through calculating the job size and CoD) through Organization should recognize the limits of what can be done and developed, hence taking control over the demand will be important at some point. Organizations should be able to determine where to begin, in what order should things be done, and when to stop and then move into something with more value and is urgent.

Prioritization, hence, should be updated on a constant basis to guarantee that the value delivers the best possible economic result for an organization or a business. CoD, at large plays a huge role in ensuring that not only SAFe or the constant flow model that is typically applied in situations wherein the ARTs or Agile Release Trains are engaged in constant and on-going development helps in eliminating delays and in keeping the system lean.  It also ensures that the business knows what will work and what will not.

Quantifying the Cost of Delay provides a plethora of benefits. However, dealing with this may be a bit overwhelming for some individuals. For those who want to be more familiar about CoD but have not muster the courage to face the fear related with numbers yet, then learning the qualitative assessment will be a good place to start.

— Slimane Zouggari

If you’re looking for the best alternative to create a better backlog that will surely help you explain your system, plan and rank your releases, story mapping is such a perfect option.

What is it?

Story mapping is a practice designed to provide a more organized approach to release planning. Also called User Story Mapping, it covers ordering user stories together with two independent proportions. The map organizes user activities alongside horizontal axis in coarse order of priority. While down the perpendicular axis, it shows rising sophistication of the application.

Story mapping organizes user stories in a valuable model to detect omissions and holes in backlog, understand system functionality and efficiently plan all-inclusive releases that provide value both to businesses and users with every release.

Why doing it?

Using story mapping has many beneficial returns that you and your business will surely benefit in the long run. Some of these expected benefits are:

• Split large requirements in small parts

Story maps will allow you to become brief when it comes to requirement description mainly because you can organize requirements in groups and deliver in small releases.

• Defers the less significant requirements to another release

It will now be easier for you to defer less significant requirements to a potential release since the requirements are distinct in smaller increments. Unlike a partial product with tough whistles and bells, your project team is more likely to achieve greater success at supplying a particular product your customer critically needs.

• Visualize the system or product roadmap

When you handed your customer a spreadsheet or document inventory with numerous page requirements, he will probably start skimming the document and miss an essential requirement that he would be held responsible to in the development period. But when you use story mapping, the focus is simply smaller and your client can visually understand the requirements delivered during the first, second or subsequent releases.

• Improve customer relationship

In terms of communication to customers, story map is an excellent tool. Your customer will clearly understand the type of functionality that will be delivered with every release, since all requirements are associated to specific process releases and steps.

What’s more, story map can be easily converted into agile project management tools such as Mingle as your product backlog.

How to do it?

The structure of your story map should be Goals > Activities > Tasks > Stories.

Group your stories by theme/application/functionality and make the grid. For instance, you can find the title for every group functionality in a horizontal way, and the main issues or stories connected to every group in a vertical way. Prioritize the functionalities from more important (left) to less important (right). Then, every group will have the stories ordered again vertically. As soon as the stories are ranked, you can now begin the surgical operation – slice the list.

Difficult as it may seem, but when you try practicing and doing it on your own, multiple benefits can be gained. Later on, you will find that story mapping is even easier than dealing with a list of stories.

— Slimane Zouggari

Estimating your project for software development is difficult. These days, lots of companies are shifting to relative estimation because it helps provide the capability of quickly assessing how long it will take to complete a project and about how much it would cost.

Relative estimation is among the few distinct flavors of estimation, which is used in Agile teams. It is consist of estimating user stories and tasks in ultimate periods of time but by grouping or comparison of items with the same difficulty.

Why Relative Estimation

There are many benefits provided by relative estimation

• It is more accurate: It may be an accurate method to plan every spirit when it comes to the money or time, which you need to be able to complete your task. However, if you run even slightly behind the schedule, your whole project’s scope may get thrown off, which is called the cone of uncertainty. When you groom the backlog, you are developing and resizing fast estimates of effort in an Agile way.
• It is fast: Relative estimation does not aim to come up with an exact level of effort when there are lots of uncertainty and there is a limited time. On the other hand, it aims to quickly get an estimation of the level of effort, and you will be able to do it much quicker as compared to what you can when you are using a traditional estimating approach.
• It is project-specific: It is almost not possible to predict an exact amount of hours for any given story. This is for the reason that hours are relative numbers. When you generalize to several significant numbers, you are allowing yourself to get more accurate velocity, which is tied to your particular project at hand.
• Getting better and better through time: Through time, you may look at how many points are getting completed by your team within a sprint, and thus, becoming much better at relative estimation. It will be a great help in gauging your development team’s as time passes by, identifying the usual capacity of your sprint, and serving as a good tool to predict the future estimates.

Difference of relative estimation over the traditional estimation

Traditional approaches require great efforts for gathering information, which result in pages of complicated documentation, as well as a project plan that has estimated dollars and hours. Given the rising popularity of this methodologies and the customer’s growing focus to save money and time, it is advocated that you build a high level of feature list and using relative estimation for a more precise estimate costs and level of effort.

You need to keep in mind that software estimation is difficult, and development has been burdened with many levels of uncertainties and complexities. You cannot perfectly estimate the span of a certain feature to be done. However, with relative estimation, you are offered with many benefits through an elegant and simple development process.

— Slimane Zouggari

The rapid development of technology enables us to complete our day-to-day tasks easily and conveniently. Among them is pair programming, which has been capturing the interest of many people, specifically businesses to improve ideas and address potential problems.

What is it?

Originated from Extreme Programming (XP), pair programming is an excellent agile technique where two developers collaborate and work in a single computer. These two developers or programmers are composed of driver (writes code) and navigator or observer (reviews all code lines as it is keyed in). Often, these programmers shift roles.

The idea is to split responsibility between the navigator and driver to maintain a stable development flow, have better structure, and avoid bugs while sharing more knowledge through the team. Though pair programming is challenging to implement since it is a big change, intense, exhausting and entails soft skills that most of the team could have not completely developed, it possesses lots of benefits that can help a business attain success that it critically needs.

Why doing it?

Over the last few years, pair programming had benefited lots of users across the world. In spite of the demands it requires, one must try what it can offer. The pay-offs you can get include:

• Greater team solidity – You are now bound to know your team better after spending full periods of time working with them. Thus, team solidity increases.
• More satisfaction of job – Mostly, programmers learn that it’s a release to share the encumbrance of code writing with a coworker. They can help each other. Meaning to say, they don’t need to beat heavy time only to finish the job on their own.
• Save time – The actual development can be quite slower of faster. With a higher quality, you and your team can save more time in refactoring code and error fixing.
• Safer and better code – Because two brains are focusing on the code, failures and errors can be minimized. At the same time, you are able to discuss various solutions and structures you wouldn’t produce alone.
• Happier team – Some think it is more satisfied and fun working with the environment by yourself. Not unless you try pair programming because it can also be your great time to make new set of friends especially with those you usually don’t spend time with.
• Higher focus – Since you’ve to team up, you’ll potentially focus more on other important tasks. A constant dialogue helps you to keep focused as well.

How to do it?

In order to have a successful pair programming, keep these important tips in mind:

1. Before sitting down, plan a reasonably definite task
2. Agree on one small goal at a time
3. Depend on your partner and show your support
4. Talk a lot. Don’t hesitate to say anything, ask for application ideas, highlight possible inputs that the code does not cover, propose clearer names for subroutines and variables, etc.
5. Sync up regularly
6. Take a time to celebrate as you finish the jobs and overcome problems
7. At least for every half hour, shift roles often

— Slimane Zouggari

The Domain-driven Design or DDD is defined as a software development approach for complex needs through connecting implementation to evolving model. The DDD’s premise includes the following:

• Basing the complex designs on a domain’s model
• Placing the primary focus of objects  domain logic and core domain
• Initiating creative relationship between domain and technical experts in order to refine conceptual model iteratively. This conceptual model tends to address certain domain problems.

The term DDD was actually coined by Eric Evans exclusively on his book with similar title. When speaking about Domain Driven Design or DDD, there is also this so called strategic design. It would ideally be preferable to have one unified model. While this is a decent goal, the truth is, it commonly fragments to multiple models. This is helpful to recognize this given fact of life and be able to work with it. Strategic design is set of principles that maintain distillation of Domain model, model integrity and work with multiple models.

Why Doing It?

Software Development approach also known as Domain-driven Design or DDD is often executed for many reasons. DDD helps individuals become more prepared to succeed in achieving effective and top quality software model designs. When DDD is implemented properly, this will help individuals reach the extent where designs are exactly how the software functions or works. The DDD book is all about helping individuals learn the proper ways of implementing DDD.

You might be new to DDD but once you have tried this, you will surely achieve better results especially if done properly. Individuals like developers and domain experts are doing DDD because this put them on level playing  field that produces software which makes some perfect sense into business and not only to coders. This does not mean just tolerating the opposite team. This means becoming a tight-knit and cohesive team.

Individuals are doing DDD because this provides software development tactics addressing both tactical and strategic design. These strategic design help individuals understand the most vital software investment that they need to make, what software assets they need to leverage on to be able to get there safest and fastest and who should be involved. The tactical designs help individuals craft one elegant model of solution utilizing proven and time tested software building blocks.

How to do Domain-driven Design (DDD)

When doing or implementing DDD, questioning the designs is always expected. Individuals have the freedom to haggle over what’s the perfect model and then settle only upon the discovered Ubiquitous Language which is agreed upon.  Ubiquitous Language pertains to shared team language. This is actually shared by the developers and domain experts alike. This can in fact be shared by everyone included in a project team. Nevertheless, individuals have to keep in mind that when doing DDD, there are idea initial steps to coin a Ubiquitous Language that perfectly fits their specific domain.

— Slimane Zouggari

Test-driven Development or TDD pertains to an exclusive software development process relying on repetition of ultimately short development cycles wherein requirements are actually turned into particular test cases. The software will then be improved to pass only the new tests. TDD is in contrary to software development which allows software to be included or added that is not actually proven to meet the requirements.

TDD is somehow linked to the concepts of test first programming for extreme programming which begun way back in 1991. However, more has just created general interest on its own right. Numerous programmers also apply this concept to- improve and debug legacy code created with older strategies and techniques.

Reasons to Do Test-Driven Development (TDD)

There are many known reasons why individuals are doing TDD and these include the following:

• Because TDD works the way you want it. TDD also helps in alleviating problems since the testing serves as specifications for what proper code to be written will do.
• Because codes will read like clear poetry. Since refactoring code is said to be a built in step in test-driven development, you will surely end up with cleaner codebase. Apps that are built with TDD are likely to have minimal duplication and few edge cases that are not thought through and overall, a better architecture.
• Because TDD saves you money. Individual and the industry tend to spend time that cost them bigger amount of money wasted every year. By means of adopting the TDD approach, money will be saved and more of this money can be spent on newest innovations instead.

How to Do It?

The following is the graphical representation of the lifecycle of Test-Driven Development or TDD:

• Add Test

In TDD, every new feature starts with writing a test which defines functions or improvements of these functions. These must be succinct. In writing a test, the developer must clearly understand the requirements and specifications of feature.

• Run All Test and Figure Out if New Test  Fails

This tends to validate that test harness functions correctly and new test does not actually mistaken pass without needing any new code and the required feature does not exist. This vital step also assesses the test itself and in the negative; this rules out possibility that new test always passes and is therefore worthless.

• Write the Code

The next step when doing TDD is writing the code that result to passing the test. The newest code written at this particular stage may not be perfect- and for instance pass this test on inelegant way. However, this is somehow acceptable because this will be honed and improved in step 5. At this certain point, the sole purpose of written code is to successfully pass the test.

• Run Test

If the entire test cases pass, programmer can now be confident that new code efficiently meet the requirement of the test and does not in any way degrade or break any existing feature.

• Refactor Code

The code base should be regularly cleaned up during TDD. New code can now be moved from where it’s convenient to pass the test where it logically belongs. Duplication should also be removed and module, method, class and object names must clearly represent their present use and purpose as added functionality is included.

— Slimane Zouggari

In computing, Birds of a Feather is usually referred to an informal group discussion. It also presents a forum for the discussion of audiences. It also intends developers’ professional networking and grass-roots participation. It is also non-commercial in a sense that it focuses on building a community via highly-interactive discussion of a lot of topics.

As compared to working groups or special interest groups, BoFs are usually formed following an ad hoc manner. This acronym is usually used by the Internet Engineering Task Force (IETF) to refer to the initial meetings wherein members are interested in a specific issue.

In such a BoF session, which is an informal form of meeting at conferences, attendees are grouped together according to their mutual interest. They also start the meeting or carry out the discussion even without the presence of a pre-planned agenda.

History

Dating back in its history or its origination, the term was once used by computer specialists. This was later on believed to be employed during a conference in DECUS. This may also have been utilized at SHARE user group-based meetings in the year of 1960.

The term was also historically derived from the proverb “Birds of a feather flock together”. As per the idiomatic phrase “birds of a feather”, it actually signifies people who have the same backgrounds, characters, beliefs or interests. In the old poetic English, it just means to say birds with the same kind of feathers. Thus, the proverb may refer to the birds that gather together with birds of the same species.

Application

BoF is usually applied to help facilitate partnership and networking formation among several subgroups. These subgroups could include functionally-oriented based groups like geographically oriented groups and CEOs. This also applies a good and consistent interaction between audiences than just the panel discussions often seen in conventions. In regard with the discussions, these are not really unguided but there is still the presence of a discussion leader.

The application of BoF in a session seeks to maximize the value of the time at a conference. When one also seeks to demonstrate a new service or a new product, it can be made possible via this group discussion. The session can also be used to give company an opportunity to talk about proprietary technology and products. Even the promotional benefits may also be clearly highlighted.

The BOF can also be an open form of discussion on various document types and the ways to consider ensuring that one has or is able to provide the forms and types of documentation that address the needs of an administrator.

In regard with the Bof Rooms, these will be fully equipped with the standardized A/V equipment like microphones, projectors and portable microphones intended for audience participation and brief presentations.

— Slimane Zouggari