Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Feed aggregator

Defining ‚ÄúScaling‚ÄĚ Agile, Part 3: Creating Agile Product Development Capabilities

In the “Scaling” Agile: Part 1, I wrote about cross-functional collaborative teams. The cross-functional collaborative feature team is the basis for “scaling” agile. In “Scaling” Agile, Part 2, I wrote about programs. I realized I need another part before my original part 3 :-). This new part 3 is about creating agile product development capabilities.

In Agile and Lean Program Management, I wrote about continuous planning. (I should have called it “continual” but I didn’t. Oh well. In the second edition I can do that :-).)

Here’s a problem I see a lot in organizations who want to “scale” agile. They plan and replan less often than they should. (I am working on a product owner book to help with that problem. It’s next in the queue.)

This lack of replanning is a legacy from the more traditional yearly planning.

When organizations planned the project portfolio on a yearly basis,¬†people didn’t perceive a need to plan the products more often. However, with agile approaches, it’s ¬†possible and helpful to plan the project portfolio on a quarterly basis, if not more often. And, in order to replan more often, the teams need to deliver finished features more often.

In Manage Your Project Portfolio, I recommend people start with quarterly planning and move to more frequent planning as the teams get better at delivering value in the form of completed features.

It’s the same idea for product management and product ownership. Product management and product ownership are two different albeit related activities.

Product management manages the product over its lifetime. Product managers meet with customers. (So should real UX people so they can create and run experiments, but that’s a different post.) Product owners are part of an agile team and work with that team on a continuous basis.

The continuous basis part is part of what the PO needs to do: create and refine (small) stories, accept stories, and replan the roadmap and the next backlog. I wrote about rolling wave replanning in Consider Rolling Wave Roadmap and Backlog Planning.

Agile approaches allow us to replan. This is particularly helpful when we want to replan the project portfolio and product roadmaps.

This graph to the left is what we¬†hope are the product’s capabilities over time. Every project helps us create more capabilities.

Agile approaches allow us to release value on a regular basis, at least as often as every month in my world. Hopefully, every week or two. If you use continuous delivery, you can release value multiple times a day.

The more often you release, the more often the people with strategy responsibilities can manage the project portfolio. Have we done enough for this project for now? If so, feed the team another product. (In my world, there are often too many products for the number of teams. We flow work through a team, so the team can move to another product.)

The more often the product value team (I’ve been calling this the product owner value team) can replan in rolling waves and help the team(s) deliver value more often, the more often the managers can change the project portfolio, the mix of projects the organization can deliver for the number of teams.

Agile product development capabilities require:

  • Cross-functional collaborative feature teams that deliver value often. The more often a team can deliver, the easier everything else is. (This is Part 1 of this series.)
  • Product owners and their colleagues to replan¬†often. Again, the more the team(s) can deliver value, the easier it is to replan.
  • Managers can then make small safe-to-fail bets on the project portfolio. If they realize the will “lose” a bet, replan the project portfolio. Choose another mix of projects to see different value from products.

That’s what I mean about agile product development capabilities. If the product development organization can become good at delivering value, the product value team people can replan what they have in the roadmap and backlog. The project portfolio people can replan the project portfolio. The product development effort in the large becomes agile.

If you have questions, please ask in the comments. I’m just starting to explain this in writing. I’m sure I am not as clear as I want to be.

Categories: Project Management

Breaking changes in Swift 4

Xebia Blog - Wed, 05/31/2017 - 13:38

In this blog I would like to give insight in the amount of code breaking changes that will be introduced in Swift 4. Also, I will demonstrate how you already can work with Swift 4 in the current Xcode 8.3.2. Breaking changes If we would summarise all implemented Swift 4 proposals, we would (as of […]

The post Breaking changes in Swift 4 appeared first on Xebia Blog.

Uncertainty: A Few Basics

No Uncertainty Here!

Uncertainty has a significant impact on both the business and engineering of software development (in all of its myriad forms). ¬†Wikipedia provides an operational definition of ‚Äėuncertainty‚Äô as, ‚Äúa situation which involves imperfect and unknown information.‚ÄĚ Defining and understanding uncertainty is important because it is a common condition across the entirety of the software development life cycle. ¬†The big BUT that follows the statement that uncertainty is common is that it is often unremarked or ignored, which are rarely useful responses. ¬†Recognizing the uncertainty in any scenario is useful in selling ideas, planning, motivation and in development. ¬†Over the course of the next several articles we will explore uncertainty across the life cycle; however, we begin with some of the sources of uncertainty and why it matters.

There are typically four macro sources of uncertainty:

  • Technology ‚Äď The translation of needs and requirements is not always as straightforward as writing a couple of lines of code. ¬†In many circumstances, the person writing the code or configuring the software has never solved the business problem before. ¬†This means that while a solution can be envisioned, the path to that solution might not be as predictable as the number of murders on the BBC‚Äôs Midsomer Murders. ¬†
  • Market ‚Äď Changes in the organization’s market, suppliers or even partners can change the business‚Äô requirements for any piece of work. ¬†The longer the time horizon the more uncertainty creeps into the effort. ¬†¬†¬†
  • Environment ‚Äď Predictions for changes to team size, government regulations, methods, techniques, and resources are often fairly limited to the very near future. ¬†Our environment can be very predictable next week but far less predictable the week after.
  • People ‚Äď How team members and stakeholders interact and how they acquire and process information is variable, and this variability generates uncertainty.

Most efforts require a lot of prediction (often known as planning, budgeting, and estimation) and assumptions, even if they can be completed in a single iteration.  As real life happens, events often overtake the best-laid plans.  The perception of uncertainty can affect team behavior:

  1. High uncertainty will affect a team’s ability to commit.
  2. Failure to properly perceive uncertainty cause teams to over commit.
  3. Higher levels of uncertainty require lower utilization rates.
  4. High uncertainty causes team anxiety and negative team behavior.
  5. Certainty can cause others to believe you are lying.
  6. Uncertainty can be a tool to generate focus.

Uncertainty is generated by different scenarios and situations.  Many of these scenarios are out of the control of an individual team but can generate very real changes in behavior. As we evaluate the impact of uncertainty we will examine both positive and negative aspects of behaviors and how we should talk about uncertainty.  


Categories: Process Management

SE-Radio Episode 292: Philipp Krenn on Elasticsearch

Phillipp Krenn talks with SE Radio‚Äôs Jeff Meyerson about Elasticsearch, a scalable search index. The conversation begins with a discussion of search, how it compares to database queries, and what an inverted index is. Phillipp introduces Wikipedia as an example that runs throughout the episode because Wikipedia uses Elasticsearch to power its full-text search. A […]
Categories: Programming

Eight Tips to Become the Scrum Master Your Team Needs

Mike Cohn's Blog - Tue, 05/30/2017 - 17:00

As a Scrum Master, do you ever feel like you’re not doing all you can for your team? Are you doing the basics of the job, yet feel you could do more?

This is a very important question to ask. We each have blind spots that prevent us from seeing some of things we could do to better help our teams.

In my work with great Scrum Masters, and those who may not be great yet but are working to get there, I’ve identified eight things people often need to be reminded of in order to become the Scrum Masters that teams need.

First Be Quiet

Embrace the effectiveness of the all important pause, the enabling power of silence. When you are tempted to speak, waiting first for others in that awkward uncomfortable stillness that follows a complicated question or thought-provoking comment. You don’t need to have all the answers.

And while you are mentally silencing yourself, remember to listen actively. Resist the temptation to begin forming a mental reply before a team member has finished speaking. Instead, while someone else is talking, give their thoughts your full attention. When they’ve finished, think before replying. There’s nothing wrong with being quiet while you decide how to reply.

Believe me when I say that to become a fully autonomous, self-organizing team, your team needs your silence more than it needs your insightful comments.

Feed Your Inner Responsibility Junkie

Although a Scrum Master does not assume responsibility for the success of the project—that charge remains with the team—a Scrum Master does assume responsibility for the team’s adoption of Scrum and practice of it.

I often compare the Scrum Master role to that of an orchestra conductor. Both must provide real-time guidance and leadership to a talented collection of individuals who come together to create something that no one of them could create alone.

Or as Boston Pops conductor Keith Lockhart says, “People assume that when you become a conductor you’re into some sort of a Napoleonic thing—that you want to stand on that big box and wield your power. I’m not a power junkie, I’m a responsibility junkie.”

So my second tip for becoming the kind of Scrum Master your team needs is to feed your inner responsibility junkie. Your responsibility is to make team members the best they can be. And part of doing that is to become the best that you can be.

Master the Art of Checking In

Third, Scrum Masters need to be aware of what’s happening with the team without crossing the line into micromanagement. To do this they need to be able to check in without making it feel like they’re checking up.

While checking up and checking in may seem similar, they are actually quite different. Scrum Masters who check in don’t just ask about progress; they offer real help in removing any obstacles or distractions that are impeding that progress. They avoid blaming individuals at all costs. And, perhaps most importantly, they ensure the team is given complete autonomy to solve whatever problem they’ve been given.

Checking up is very different. When you check up on someone, you are looking for conformance to a plan--did the programmer finish the changes last night as she said she would? Did the tester automate the tests as promised or just run them manually “one more time” again?

Checking up is about getting status-type information. That’s fine. But checking in goes beyond that to include offering to help remove any impediments to progress.

To be the kind of Scrum Master your team needs, practice and perfect the art of checking in without checking up.

Showcase the Team

Scrum Masters look good when their teams look good. As such, they do whatever is necessary to help the team achieve its goal. And when the team achieves something extraordinary, great ScrumMasters make sure everyone in the organization takes note.

Good Scrum Masters also help their teams celebrate their successes. The celebration doesn’t need to be massive. You don’t need to have The Rolling Stones play at your retrospective. (But if you do, invite me, please.)

Food is always a good way to celebrate. I’ve brought bagels, homemade cookies (yes, I can cook), or everyone’s personalized favorite morning drink. An afternoon off to go to the movies together is great. I once took a team bowling, which was a blast because the alley displayed the speed of each ball. We paid more attention to that than to the number of pins knocked down.

You helped the team achieve their success. And that’s very important. But they achieved it. Make sure they--and others--recognize and respect that fact.

So that’s my fourth tip: To be the Scrum Master your team needs, make the shift in your own head from “Look what I did!” to “Look what I helped the team do!”

Clear a Path

Fifth, try to end each day with all known impediments resolved. That doesn’t mean you can necessarily clear every impediment by the end of the day--some impediments take some time and maneuvering to remove. But you should make some progress every single day.

Remember, to be the Scrum Master your team needs you to be, you don’t need to do the work--you need to make the work easier for the team to accomplish.

Be the Hardliner Your Team Needs You to Be

This sixth tip might seem counterintuitive. But sometimes you’ve got to be a bit of a jerk. By that I mean, you need to be unbending when it comes to certain rules and uncompromising in your confidence in the team’s ability to find a way forward.

Here are just a few examples:

Never let the team team get away with taking partial credit for a story.

Don’t let the team honor only the agile principles they find the most enjoyable. For example, many teams incorrectly interpret the Agile Manifesto to say that no documentation is needed. And they relish in that while treating working software as something nice to have but not necessary at the end of each sprint.

Don’t solve problems for the team they should solve themselves. Sometimes working together to solve a problem helps a team identify ways to make sure the problem doesn’t recur.

Push the team to improve. Are too many bugs escaping into production? That might be a good time to suggest incorporating new engineering practices: test-driven development, pair programming, continuous delivery or so on.

Insist on timely participation in every daily scrum. Be vigilant about getting everyone’s input in team discussions such as sprint retrospectives.

Hold the team to account…every sprint…every time. Your team might not always like it at first, but soon they’ll come to recognize the benefits of holding steadfast to agile principles.

Know Your Stuff -- And Learn What You Don’t

The best Scrum Masters have the technical, market, or specific knowledge to help the team in pursuit of its goal.

That means knowing enough about key technical issues to understand the problem and be able to explain it to others in the organization when necessary.

It also includes having a broad understanding of the market and the opportunities and challenges surrounding the product.

And it means knowing how decisions are made in the organization, who makes them, which coalitions exist, and so on.

So my seventh tip is this: If you don’t have all of these skills, work to acquire them. This doesn’t mean you need to become a developer or marketer. But you need to know enough about those types of work that you can assist resolving problems that affect those areas of your team’s effort.

Assert Influence without Taking Over

That brings us to the eighth and final tip: Successful Scrum Masters know how to influence others, both on the team and outside it.

Initially, team members may need to be influenced to give Scrum a fair trial or to behave more collaboratively; later a Scrum Master may sell a team on the idea of trying on the idea of trying new technical practices such as test-driven development or pair programming. A Scrum Master should know how to exert influence without resorting to a command-and-control “because I say so” style.

Most Scrum Masters will also be called upon to influence those outside the team. A traditional team may need to be convinced to provide a partial implementation of their functionality to the Scrum team, a QA director may need to be persuaded to dedicate full-time testers to the project, or a vice president may need to be talked into trying Scrum at all.

To be the Scrum Master your self-organizing team needs you to be, you need to do more than buy pizza and get out of the way. Learn how to influence the team and those surrounding the team in subtle and indirect ways. When you do, you can steadily move teams (and the organization itself) toward becoming more agile--which ultimately is what everyone really needs.

What Do You Think?

Whether you’re a Scrum Master or team members, what reminders would you offer Scrum Masters who want to become the Scrum Masters their teams need? Please add your thoughts in the comments section.

Request a professional app translation from the Google Play Console and reach new users

Android Developers Blog - Tue, 05/30/2017 - 16:12
.post-content img { padding: 20px 0 10px 0; } b { color: gold; } .stars { color: gold; text-align: center; } .use { font-style: italic; font-size: 8pt; text-align: center; } Posted by Rahim Nathwani, Product Manager, Google Play
Localizing your app or game is an important step in allowing you to reach the widest possible audience. It helps you increase downloads and provide better experiences for your audience.
To help do this, Google Play offers an app translation service. The service, by professional linguists, can translate app user interface strings, Play Store text, in-app products and universal app campaign ads. We've made the app translation service available directly from inside the Google Play Console, making it easy and quick to get started.
  • Choose from a selection of professional translation vendors.
  • Order, receive and apply translations, without leaving the Play Console.
  • Pay online with Google Wallet.
  • Translations from your previous orders (if any) are reused, so you never pay for the same translation twice. Great if you release new versions frequently.
Using the app translation service to translate a typical app and store description into one language may cost around US$50. (cost depends on the amount of text and languages).
Find out more and get started with the app translation service.

How useful did you find this blogpost? ‚ėÖ ‚ėÖ ‚ėÖ ‚ėÖ ‚ėÖ
Categories: Programming

Software Development Conferences Forecast May 2017

From the Editor of Methods & Tools - Tue, 05/30/2017 - 14:56
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

SPaMCAST 444 ‚Äď Product Owner ‚Äď The Hard Role, QA Value, Work In Process Limits

SPaMCAST Logo

http://www.spamcast.net

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

This week’s Software Process and Measurement Cast features our essay revisiting the product owner role. The product owner role is hard, often messed up and a great opportunity for improvement.

The second column features the return of Steve Tendon talking about Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 17 which is titled Challenges of Work-State Work in Process Limits. WIP limits have their plusses and minuses when discussing hyper-productivity.  

Our third column this week is from Jeremy Berriault. Jeremy discusses how to show the value of QA and why knowing and showing value is important!   Jeremy  blogs at https://jberria.wordpress.com/  

 

Re-Read Saturday News

This week we tackle Chapter 6 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.   Chapter 6, Facilitating Governance, puts the ideas and processes defined in governance to work.

Catch up on the first four entries in the re-read

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes.  Reviews help guide people to the cast!

Next SPaMCAST

SPaMCAST 445 features the return of a favorite, Capers Jones.  Capers and I talked about his new book, A Guide to Selecting Software Measures and Metrics. As usual, Capers was engaging, educational and controversial.  Spending time with Capers is always worthwhile!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 444 - Product Owner - The Hard Role, QA Value, Work In Process Limits

Software Process and Measurement Cast - Sun, 05/28/2017 - 22:00

This week’s Software Process and Measurement Cast features our essay revisiting the product owner role. The product owner role is hard, often messed up and a great opportunity for improvement.

The second column features the return of Steve Tendon talking about Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 17 which is titled Challenges of Work-State Work in Process Limits. WIP limits have their plusses and minuses when discussing hyper-productivity.  

Our third column this week is from Jeremy Berriault. Jeremy discusses how to show the value of QA and why knowing and showing value is important!   Jeremy  blogs at https://jberria.wordpress.com/  

 

Re-Read Saturday News

This week we tackle Chapter 6 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.   Chapter 6, Facilitating Governance, puts the ideas and processes defined in governance to work.

Catch up on the first four entries in the re-read

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes.  Reviews help guide people to the cast!

Next SPaMCAST

SPaMCAST 445 features the return of a favorite, Capers Jones.  Capers and I talked about his new book, A Guide to Selecting Software Measures and Metrics. As usual, Capers was engaging, educational and controversial.  Spending time with Capers is always worthwhile!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

SPaMCAST 444 - Product Owner - The Hard Role, QA Value, Work In Process Limits

Software Process and Measurement Cast - Sun, 05/28/2017 - 22:00

This week’s Software Process and Measurement Cast features our essay revisiting the product owner role. The product owner role is hard, often messed up and a great opportunity for improvement.

The second column features the return of Steve Tendon talking about Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 17 which is titled Challenges of Work-State Work in Process Limits. WIP limits have their plusses and minuses when discussing hyper-productivity.  

Our third column this week is from Jeremy Berriault. Jeremy discusses how to show the value of QA and why knowing and showing value is important!   Jeremy  blogs at https://jberria.wordpress.com/  

 

Re-Read Saturday News

This week we tackle Chapter 6 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.   Chapter 6, Facilitating Governance, puts the ideas and processes defined in governance to work.

Catch up on the first four entries in the re-read

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes.  Reviews help guide people to the cast!

Next SPaMCAST

SPaMCAST 445 features the return of a favorite, Capers Jones.  Capers and I talked about his new book, A Guide to Selecting Software Measures and Metrics. As usual, Capers was engaging, educational and controversial.  Spending time with Capers is always worthwhile!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

Projects and Products

Herding Cats - Glen Alleman - Sun, 05/28/2017 - 15:47

It's popular in the Agile world to speak of Products and their value creation and the notion that Projects are not needed for this. The notion of #NoProjects follows the same logic as #Noestimates. There are #NoPrinciples at the foundation of both these hashtags. Here's a nice summary of what is a project.

 

Projects Produce Products

It's that simple. When we speak of a product the fist question is how is that product development funded?  Does that funding have a period of performance? Does that funding have an upper limit? If the answer to any of these is Yes then the funding for the product is finite, it's bounded. 

Then ask, does the product result in a change to the environment, market, revenue stream, cost savings, anything? Yes, then the product and the project that manages those changes are connected.

Does the product participate in the execution of strategy? Yes? Then the Product is part of the Strategic Project.

The #NoProjects advocates, like the #NoEstimates advocates, fail to see both sides of how business works.

The value of any endevor cannot be determined unless the cost to acheive that value is also known. Cost and Value are inseperable.
Projects produce Products

Categories: Project Management

Holacracy: Re-read Week 7, Chapter 6 ‚Äď Facilitating Governance

Book Cover

Holacracy

This week we tackle Chapter 6 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 6, Facilitating Governance, puts the ideas and processes defined in governance to work.

The description of operations meetings as we discovered earlier in the book is fairly straightforward; however, the process is generally messier than the pristine words printed in the book suggest, especially when dealing with problems. ¬†The facilitator role in Holacracy is crucial¬†to actually get things done, but the role of the facilitator is different. ¬†In Holacracy, the role of the facilitator is to protect the process which allows people to take care of themselves, not to protect or support the people. ¬†A facilitator in Holacracy needs to override your instinct to be nice or polite and cut people off they speak out of turn. The facilitator must keep the process on track by ruthlessly cutting them off even at ‚Äúthe first intake of breath‚ÄĚ (Roberston‚Äôs suggestion). ¬†In other words, the facilitator role is not for the faint of heart. ¬†The person playing the role needs to be as neutral and impersonal as possible with the goal of keeping meeting explicitly on the processes rather than guiding it to an outcome. Recently when I was discussing Holacracy with a practitioner, this process absolutism was noted as the hardest part of actually ‚Äúdoing‚ÄĚ Holacracy and the biggest payoff.

One of the critical parts of the facilitator role is to determine what is valid to process during a governance meeting.  As noted in Chapter 4, governance meetings perform a very specific set of activities:

  1.      Creating, amending or moving roles with the circle (see Chapter 3)
  2.      Creating, amending or removing policies within the circle’s domain.
  3.      Electing circle members to fill elected rules facilitator, secretary, and representative link.
  4.      Creating amending or dissolving sub-circles.

For the proposal to be valid to process in a governance meeting, the tension/issue driving the proposal must somehow limit ones of the proposer‚Äôs roles and the goal of the proposal must be to remove that limit. The proposal may modify other roles as long as the reason is to help one of the proposer‚Äôs roles. The first filter the facilitator applies is to accept, reject or discard the proposal based on whether the¬†proposer can give a concrete example of how the proposal will¬†improve¬†his or her ability to express the purpose or accountabilities of one of their roles. Robertson points out that this ‚Äúshow me‚ÄĚ (my term for the rule) will filter out two types of proposals. First are attempts to improve everything, including things that aren‚Äôt the prospers to improve in the first place. Second are the proposals that would serve the proposer personally, but not the role they are stewarding in the organization. ¬†Remember that the facilitator role and governance are part of a process that is a steward for the process, not to ensure personal needs are met. ¬†

A substantial portion of the chapter is turned over to basic blocking and tackling mechanisms of facilitating in Holacracy.  

  1. The process: One tension/proposal at a time.

The facilitator gets one proposal at a time into active consideration. ¬†He/she then invites clarifying questions from other in the governance meeting. ¬†Clarifying questions are not reactions or statements. Once clarifying questions have been covered, a reaction round follows. ¬†Address one reaction at a time, round-robin style until all reactions are dealt with ¬†Reactions are directed at space not at the individual and no crosstalk is allowed. When all reactions have been stated the facilitator checks with the proposer to see whether they want or clarify the proposal. ¬†The facilitator, in this part of the process, needs to make sure that the proposer is focusing on his or her roles tension/issue and to ignore everything else if it doesn’t help with the specific tension there trying to address.

  1. The Process: Testing objections

After reacting to reactions (nice alliteration), the facilitator asks the assembled group whether they see any reasons why adopting proposal would move the goal of the circle backward.  At this point, the answer is an objection or no objection.  If objection, the person making the object needs to state objections.  Objections need to both explain why the proposal will move the circle backward and describe how the proposal would diminish the roles capacity to express its purpose or to enact its accountabilities.  The facilitator must immediately determine whether the objection is valid or not.  Robertson provides four criteria for determining whether an objective is valid or not.   Objections are valid if:

  1. If the proposal would hurt the circle.
  2. The objection is created by adopting the proposal and would not exist if the proposal was dropped.
  3. The objection arises from known (tangible) data or if based on a forecast/prediction there would not be time to react before harm occurred.
  4. If the proposal was adopted the objection could be processed as a proposal in its own right.

Robertson provides a decision tree on page 118 to help apply the rules.  It took reading the rules a few times for me to see the internal logic of the rules.  If the proposal hurts the circle by adoption or would cause a scenario in which the goal of the circle is negatively impacted it is valid to be processed.  The facilitator applies the rules so that the circle can recognize the validity of the objections.

Once all of the objections have been voiced the proposer is asked to integrate the valid objections into an amended proposal.  The facilitator performs a focusing role during the integration step by asking questions to determine if the proposal is reformed to address the original tension/problem while addressing the voiced objections.  Once the proposal is reformed the objection round is repeated until all objections are addressed or the proposal is withdrawn.

Governance processes are straightforward but the simplicity obscures the really hard part of making Holacracy work.  Applying Holacracy requires separating the person from the process which is where the role of the facilitator fits in.

Remember to buy a copy of Holacracy (use the link to help support and defray the costs of the Software Process and Measurement Cast blog and podcast).

Previous Entries in the re-read:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organization Structure

Week 5: Governance

Week 6: Operations


Categories: Process Management

Holacracy: Re-read Week 7, Chapter 6 ‚Äď Facilitating Governance

Book Cover

Holacracy

This week we tackle Chapter 6 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 6, Facilitating Governance, puts the ideas and processes defined in governance to work.

The description of operations meetings as we discovered earlier in the book is fairly straightforward; however, the process is generally messier than the pristine words printed in the book suggest, especially when dealing with problems. ¬†The facilitator role in Holacracy is crucial¬†to actually get things done, but the role of the facilitator is different. ¬†In Holacracy, the role of the facilitator is to protect the process which allows people to take care of themselves, not to protect or support the people. ¬†A facilitator in Holacracy needs to override your instinct to be nice or polite and cut people off they speak out of turn. The facilitator must keep the process on track by ruthlessly cutting them off even at ‚Äúthe first intake of breath‚ÄĚ (Roberston‚Äôs suggestion). ¬†In other words, the facilitator role is not for the faint of heart. ¬†The person playing the role needs to be as neutral and impersonal as possible with the goal of keeping meeting explicitly on the processes rather than guiding it to an outcome. Recently when I was discussing Holacracy with a practitioner, this process absolutism was noted as the hardest part of actually ‚Äúdoing‚ÄĚ Holacracy and the biggest payoff.

One of the critical parts of the facilitator role is to determine what is valid to process during a governance meeting.  As noted in Chapter 4, governance meetings perform a very specific set of activities:

  1.      Creating, amending or moving roles with the circle (see Chapter 3)
  2.      Creating, amending or removing policies within the circle’s domain.
  3.      Electing circle members to fill elected rules facilitator, secretary, and representative link.
  4.      Creating amending or dissolving sub-circles.

For the proposal to be valid to process in a governance meeting, the tension/issue driving the proposal must somehow limit ones of the proposer‚Äôs roles and the goal of the proposal must be to remove that limit. The proposal may modify other roles as long as the reason is to help one of the proposer‚Äôs roles. The first filter the facilitator applies is to accept, reject or discard the proposal based on whether the¬†proposer can give a concrete example of how the proposal will¬†improve¬†his or her ability to express the purpose or accountabilities of one of their roles. Robertson points out that this ‚Äúshow me‚ÄĚ (my term for the rule) will filter out two types of proposals. First are attempts to improve everything, including things that aren‚Äôt the prospers to improve in the first place. Second are the proposals that would serve the proposer personally, but not the role they are stewarding in the organization. ¬†Remember that the facilitator role and governance are part of a process that is a steward for the process, not to ensure personal needs are met. ¬†

A substantial portion of the chapter is turned over to basic blocking and tackling mechanisms of facilitating in Holacracy.  

  1. The process: One tension/proposal at a time.

The facilitator gets one proposal at a time into active consideration. ¬†He/she then invites clarifying questions from other in the governance meeting. ¬†Clarifying questions are not reactions or statements. Once clarifying questions have been covered, a reaction round follows. ¬†Address one reaction at a time, round-robin style until all reactions are dealt with ¬†Reactions are directed at space not at the individual and no crosstalk is allowed. When all reactions have been stated the facilitator checks with the proposer to see whether they want or clarify the proposal. ¬†The facilitator, in this part of the process, needs to make sure that the proposer is focusing on his or her roles tension/issue and to ignore everything else if it doesn’t help with the specific tension there trying to address.

  1. The Process: Testing objections

After reacting to reactions (nice alliteration), the facilitator asks the assembled group whether they see any reasons why adopting proposal would move the goal of the circle backward.  At this point, the answer is an objection or no objection.  If objection, the person making the object needs to state objections.  Objections need to both explain why the proposal will move the circle backward and describe how the proposal would diminish the roles capacity to express its purpose or to enact its accountabilities.  The facilitator must immediately determine whether the objection is valid or not.  Robertson provides four criteria for determining whether an objective is valid or not.   Objections are valid if:

  1. If the proposal would hurt the circle.
  2. The objection is created by adopting the proposal and would not exist if the proposal was dropped.
  3. The objection arises from known (tangible) data or if based on a forecast/prediction there would not be time to react before harm occurred.
  4. If the proposal was adopted the objection could be processed as a proposal in its own right.

Robertson provides a decision tree on page 118 to help apply the rules.  It took reading the rules a few times for me to see the internal logic of the rules.  If the proposal hurts the circle by adoption or would cause a scenario in which the goal of the circle is negatively impacted it is valid to be processed.  The facilitator applies the rules so that the circle can recognize the validity of the objections.

Once all of the objections have been voiced the proposer is asked to integrate the valid objections into an amended proposal.  The facilitator performs a focusing role during the integration step by asking questions to determine if the proposal is reformed to address the original tension/problem while addressing the voiced objections.  Once the proposal is reformed the objection round is repeated until all objections are addressed or the proposal is withdrawn.

Governance processes are straightforward but the simplicity obscures the really hard part of making Holacracy work.  Applying Holacracy requires separating the person from the process which is where the role of the facilitator fits in.

Remember to buy a copy of Holacracy (use the link to help support and defray the costs of the Software Process and Measurement Cast blog and podcast).

Previous Entries in the re-read:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organization Structure

Week 5: Governance

Week 6: Operations


Categories: Process Management

Quote of the Day

Herding Cats - Glen Alleman - Sat, 05/27/2017 - 14:56

"We confide in our strength, without boasting of it; we respect that of others, without fearing it."
Thomas Jefferson

Categories: Project Management

GraphQL-Europe: A trip to Berlin

Mark Needham - Sat, 05/27/2017 - 12:31

Last weekend my colleagues Will, Michael, Oskar, and I went to Berlin to spend Sunday at the GraphQL Europe conference in Berlin.

IMG 20170521 084449

Neo4j sponsored the conference as we’ve been experimenting with building a GraphQL to Neo4j integration and wanted to get some feedback from the community as well as learn what’s going on in GraphQL land.

Will and Michael have written about their experience where they talk more about the hackathon we hosted so I’ll cover it more from a personal perspective.

The first thing that stood out for me was how busy it was – I knew GraphQL was pretty hipster but I wasn’t expecting there to be ~ 300 attendees.

The venue was amazing – the nHow Hotel is located right next to the Spree River so there were great views to be had during the breaks. It also helped that it was really sunny for the whole day!

IMG 20170521 103636

I spent most of the day hanging out at the Neo4j booth which was good fun – several people pointed out that an integration between Neo4j and GraphQL made a lot of sense given that GraphQL talks about the application graph and Neo4j graphs in general.

I managed to attend a few of the talks, including one by Brooks Swinnerton from GitHub who announced that they’d be moving to GraphQL for v4 of their API.

The most interesting part of the talk for me was when Brooks said they’d directed requests for their REST API to the GraphQL one behind the scenes for a while now to check that it could handle the load.

GitHub is moving to GraphQL for v4 of our API because it offers significantly more flexibility for our integrators. The ability to define precisely the data you want‚ÄĒand only the data you want‚ÄĒis a powerful advantage over the REST API v3 endpoints.

I think twitter may be doing something similar based on this tweet by Tom Ashworth:

Heh. Twitter GraphQL is quietly serving more than 40 million queries per day. Tiny at Twitter scale but not a bad start.

— tom (@tgvashworth) May 9, 2017

From what I could tell the early pick up of GraphQL seems to be from the front end of applications – several of the attendees had attended ReactEurope a couple of days earlier – but micro services were mentioned in a few of the talks and it was suggested that GraphQL works well in this world as well.

It was a fun day out so thanks to the folks at Graphcool for organising!

The post GraphQL-Europe: A trip to Berlin appeared first on Mark Needham.

Categories: Programming

What's new from Firebase at Google I/O 2017

Google Code Blog - Fri, 05/26/2017 - 18:00
Originally posted on the Firebase Blog by Francis Ma, Firebase Group Product Manager

It's been an exciting year! Last May, we expanded Firebase into our unified app platform, building on the original backend-as-a-service and adding products to help developers grow their user base, as well as test and monetize their apps. Hearing from developers like Wattpad, who built an app using Firebase in only 3 weeks, makes all the hard work worthwhile.

We're thrilled by the initial response from the community, but we believe our journey is just getting started. Let's talk about some of the enhancements coming to Firebase today.

Integrating with Fabric

In January, we announced that we were welcoming the Fabric team to Firebase. Fabric initially grabbed our attention with their array of products, including the industry-leading crash reporting tool, Crashlytics. As we got to know the team better, we were even more impressed by how closely aligned our missions are: to help developers build better apps and grow successful businesses. Over the last several months, we've been working closely with the Fabric team to bring the best of our platforms together.

We plan to make Crashlytics the primary crash reporting product in Firebase. If you don't already use a crash reporting tool, we recommend you take a look at Crashlytics and see what it can do for you. You can get started by following the Fabric documentation.

Phone authentication comes to Firebase

Phone number authentication has been the biggest request for Firebase Authentication, so we're excited to announce that we've worked with the Fabric Digits team to bring phone auth to our platform. You can now let your users sign in with their phone numbers, in addition to traditional email/password or identity providers like Google or Facebook. This gives you a comprehensive authentication solution no matter who your users are or how they like to log in.

At the same time, the Fabric team will be retiring the Digits name and SDK. If you currently use Digits, over the next couple weeks we'll be rolling out the ability to link your existing Digits account with Firebase and swap in the Firebase SDK for the Digits SDK. Go to the Digits blog to learn more.

Introducing Firebase Performance Monitoring

We recognize that poor app performance and stability are the top reasons for users to leave bad ratings on your app and possibly churn altogether. As part of our effort to help you build better apps, we're pleased to announce the beta launch of Performance Monitoring.

Firebase Performance Monitoring is a new free tool that helps you understand when your user experience is being impacted by poorly performing code or challenging network conditions. You can learn more and get started with Performance Monitoring in the Firebase documentation.

More robust analytics

Analytics has been core to the Firebase platform since we launched last I/O. We know that understanding your users is the number one way to make your app successful, so we're continuing to invest in improving our analytics product.

First off, you may notice that you're starting to see the name "Google Analytics for Firebase" around our documentation. Our analytics solution was built in conjunction with the Google Analytics team, and the reports are available both in the Firebase console and the Google Analytics interface. So, we're renaming Firebase Analytics to Google Analytics for Firebase, to reflect that your app analytics data are shared across both.

For those of you who monetize your app with AdMob, we've started sharing data between the two platforms, helping you understand the true lifetime value (LTV) of your users, from both purchases and AdMob revenue. You'll see these new insights surfaced in the updated Analytics dashboard.

Many of you have also asked for analytics insights into custom events and parameters. Starting today, you can register up to 50 custom event parameters and see their details in your Analytics reports. Learn more about custom parameter reporting.

Firebase for all - iOS, games, and open source

Firebase's mission is to help all developers build better apps. In that spirit, today we're announcing expanded platform and vertical support for Firebase.

First of all, as Swift has become the preferred language for many iOS developers, we've updated our SDK to handle Swift language nuances, making Swift development a native experience on Firebase.

We've also improved Firebase Cloud Messaging by adding support for token-based authentication for APNs, and greatly simplifying the connection and registration logic in the client SDK.

Second, we've heard from our game developer community that one of the most important stats you monitor is frames per second (FPS). So, we've built Game Loop support & FPS monitoring into Test Lab for Android, allowing you to evaluate your game's frame rate before you deploy. Coupled with the addition of Unity plugins and a C++ SDK, which we announced at GDC this year, we think that Firebase is a great option for game developers. To see an example of a game built on top of Firebase, check out our Mecha Hamster app on Github.

Finally, we've taken a big first step towards open sourcing our SDKs. We believe in open source software, not only because transparency is an important goal, but also because we know that the greatest innovation happens when we all collaborate. You can view our new repos on our open sourceproject page and learn more about our decision in this blog post.

Dynamic Hosting with Cloud Functions for Firebase

In March, we launched Cloud Functions for Firebase, which lets you run custom backend code in response to events triggered by Firebase features and HTTP requests. This lets you do things like send a notification when a user signs up or automatically create thumbnails when an image is uploaded to Cloud Storage.

Today, in an effort to better serve our web developer community, we're expanding Firebase Hosting to integrate with Cloud Functions. This means that, in addition to serving static assets for your web app, you can now serve dynamic content, generated by Cloud Functions, through Firebase Hosting. For those of you building progressive web apps, Firebase Hosting + Cloud Functions allows you to go completely server-less. You can learn more by visiting our documentation.

Firebase Alpha program and what's next

Our goal is to build the best developer experience: easy-to-use products, great documentation, and intuitive APIs. And the best resource that we have for improving Firebase is you! Your questions and feedback continuously push us to make Firebase better.

In light of that, we're excited to announce a Firebase Alpha program, where you will have the opportunity to test the cutting edge of our products. Things might not be perfect (in fact, we can almost guarantee they won't be), but by participating in the alpha community, you'll help define the future of Firebase. If you want to get involved, please register your interest in the Firebase Alpha form.

Thank you for your support, enthusiasm, and, most importantly, feedback. The Firebase community is the reason that we've been able to grow and improve our platform at such an incredible pace over the last year. We're excited to continue working with you to build simple, intuitive products for developing apps and growing mobile businesses. To get started with Firebase today, visit our newly redesigned website. We're excited to see what you build!

Categories: Programming

Meet 5 Android developers working to improve lives around the world

Android Developers Blog - Fri, 05/26/2017 - 17:00
.asset img { width: 200px; text-align: center; padding: 0; border: 0; margin: auto; display: block; } .caption { text-align: center; font-size: 6pts; font-style: italic; padding: 10px 0 0 0; margin: 0; border: 0; } .use { text-align: center; font-size: 6pts; padding:10px 0 0 0; margin: 0; border: 0; .stars { text-align: center; } Posted by Maxim Mai, Apps Partnerships, Google Play

Last Thursday at Google I/O 2017, we announced the winners of this year's Google Play Awards. Grab some popcorn and watch the award ceremony, we think it's just as fun as The Oscars. This year, we included a category to celebrate the achievements of developers who publish outstanding apps that have positive social impact.

In introducing this awards category, we were inspired by the UN's 17 Sustainable Development Goals. With the ability to reach over 1 billion active Android devices around the world, we think that app developers have a tremendous opportunity to impact Zero Hunger (SDG #2), Good Health and Wellbeing (SDG #3) and Quality Education (SDG #4), and many others. Read on to find out more about how this year's winner and finalists and impacting these goals.

Get in touch about your social impact app or game

Our work in supporting developer success in this area on Android and Google Play is just beginning. We would like to encourage Android developers with a focus on social impact to get in touch with us here at Google Play and to tell us about their app or game. It doesn't matter where you are based, what problems you are solving, or which countries you are targeting, we would like to hear your story and maybe we can help you grow faster and improve your app's quality.

Social impact winner & finalists in the 2017 Google Play Awards
Categories: Programming

Meet 5 Android developers working to improve lives around the world

Android Developers Blog - Fri, 05/26/2017 - 17:00
.asset img { width: 200px; text-align: center; padding: 0; border: 0; margin: auto; display: block; } .caption { text-align: center; font-size: 6pts; font-style: italic; padding: 10px 0 0 0; margin: 0; border: 0; } .use { text-align: center; font-size: 6pts; padding:10px 0 0 0; margin: 0; border: 0; .stars { text-align: center; } Posted by Maxim Mai, Apps Partnerships, Google Play

Last Thursday at Google I/O 2017, we announced the winners of this year's Google Play Awards. Grab some popcorn and watch the award ceremony, we think it's just as fun as The Oscars. This year, we included a category to celebrate the achievements of developers who publish outstanding apps that have positive social impact.

In introducing this awards category, we were inspired by the UN's 17 Sustainable Development Goals. With the ability to reach over 1 billion active Android devices around the world, we think that app developers have a tremendous opportunity to impact Zero Hunger (SDG #2), Good Health and Wellbeing (SDG #3) and Quality Education (SDG #4), and many others. Read on to find out more about how this year's winner and finalists and impacting these goals.

Get in touch about your social impact app or game

Our work in supporting developer success in this area on Android and Google Play is just beginning. We would like to encourage Android developers with a focus on social impact to get in touch with us here at Google Play and to tell us about their app or game. It doesn't matter where you are based, what problems you are solving, or which countries you are targeting, we would like to hear your story and maybe we can help you grow faster and improve your app's quality.

Social impact winner & finalists in the 2017 Google Play Awards
Categories: Programming

Stuff The Internet Says On Scalability For May 26th, 2017

Hey, it's HighScalability time:

 

 

Sport imitating tech. Cloud Computing chases down Classic Empire to win...the Preakness. (Daily News)
If you like this sort of Stuff then please support me on Patreon.
  • 42%: increase US wireless traffic since 2015; 44: age of Ethernet; $18.5m: low cost of Target data breach; 25 million: record set from Library of Congress; 98%: WannaCry infections on Windows 7; 100 terabytes: daily Pinterest logging; 2020: when Microsoft will have DNA storage in the cloud; 220 μm: size of microbots; 2 billion: lines of code in Google repository; 40%+: esports industry growth; 

  • Quotable Quotes:
    • @Werner: There is no compression algorithm for experience.
    • @colinmckerrache: We just crossed over 2m EVs on the road. So yeah, second million took just under 18 months. Next million in about 10 months.
    • @swardley: When discussing China, stop thinking cheap labour, communism & copying ... to understand changes, start thinking World's largest VC.
    • @JOTB17: "Cars generate more than 4Tb of data a day, humans are becoming irrelevant in data collection"
Categories: Architecture

Asking Questions: 7 Behaviors to Avoid

Questions, like most tools, can be used correctly or incorrectly.  A hammer used on a nail or on a screw is still a hammer; however, in most circumstances, we would debate the effectiveness of the hammer when used to insert a screw.  Questions are no different than our proverbial hammer.  Used well they can generate information or shape behavior; used incorrectly they can generate misinformation and friction. When questions are used for coaching and mentoring there are a number of poor practices that should be avoided:

  1. Actively listen to the answer.  Really listening generates a connection between the parties in the conversation.  Listening also helps to ensure you don’t appear stupid if you don’t listen to the answer.  How many times have you heard someone ask the same question again because they weren’t really listening?  It is infuriating.
  2. If you don’t want to hear the answer, don’t ask the question.  This is a corollary to listening, but far darker.  Note: Not wanting to listen to an answer is different than being afraid of the answer.
  3. Don’t expect or imply exposition if you ask yes/no questions.  Some questioners will ask a yes/or no question and then expect the person answering the question to keep going or worse jump to a conclusion about why the person answered the question the way they did.  If you want more, ask why.
  4. Try not to talk when in moments of silence.  Silence is a questioner’s friend (but a really insightful answer is his or her best friend).  After the person answering the question stops talking continue listening. Nature abhors both a vacuum and silence; if you don’t fill the silence the person answering the question will read silence as a signal that you want them to continue.
  5. Don’t go out of your way to irritate the person you are talking with.  Most coaching and mentoring are scenarios should not be patterned after aggressive television or radio interview shows.  Spectacle, while interesting entertainment, will not help someone you are coaching or mentoring to have an epiphany and many cause them to withdraw.
  6. It‚Äôs not about YOU! You are asking someone else what they know, think or feel. ¬†What you know, think, or feel might be useful scripting or phrasing the question, your goal is not to put your words in their mouth. ¬†Be very careful that how you ask a question does not cause a specific answer unless you are trying to make that happen. ¬†This form of questioning is very prevalent in legal proceedings (go listen to an actual court case — not Law and Order), but is far less useful during an agile retrospective. ¬†
  7. Rhetorical questions aren‚Äôt really questions. Rhetorical questions are a great presentation device but are really statements representing what the person using them believes. ¬†They are useful for establishing a line in the sand and then daring the listener to cross the line. ¬†An example of a rhetorical question asked by George Carlin was, ‚ÄúIsn’t it a bit unnerving that doctors call what they do ‘practice’?” A great tool to make a statement, but not useful to elicit an open conversation.

When I go out to mow the lawn, I rarely bring my hammer with me. ¬†I do bring my lawnmower, headphones, and a large screwdriver (for popping weeds out the lawn ‚Äď pretty darn effective). Using the right tool for the right mission increases effectiveness and efficiency. ¬†Using the right questions and using the right questions in the right way have the same effect! ¬†¬†

Other entries in the Asking Question Theme:

Asking Questions: A Coach’s Super Power or Kryptonite

Asking Questions: Many Types of Questions

Asking Questions: Hints for Improving Your Question Making Skills

 


Categories: Process Management